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ABSTRACT 


An  object-oriented  simulation  model  is  developed  to 
evaluate  the  effectiveness  of  NATO  Standardization  Agreement 
(STANAG)  4214,  which  promulgates  the  protocol  for 
international  telephone  call  routing  and  directories  for 
tactical  communications.  The  model  simulates  communication 
systems  using  the  STANAG  4214  protocol  to  isolate 
discrepancies  which  could  lead  to  the  inability  to 
successfully  complete  calls  within  the  system.  The  model  also 
simulates  protocol  modifications  created  to  correct  existing 
discrepancies  and  verifies  their  effectiveness  in  making  the 
protocol  more  robust.  Results  show  that  these  modifications 
improve  STANAG  call  completion  rate  from  a  potential  low  of 
under  70  percent  to  100  percent,  while  simultaneously  easing 
the  restrictions  on  lateral  communication  connections.  The 
model  is  menu-driven  with  both  graphical  and  hard  copy  output, 
making  it  useful  to  network  planners,  protocol  designers,  and 
tactical  communications  officers. 
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EXECUTIVE  SUMMARY 


The  Joint  Interoperability  Engineering  Organization  (JIEO) 
is  responsible  for  ensuring  communication  systems 
interoperability  with  United  States  allies,  including  North 
Atlantic  Treaty  Organization  (NATO)  allies.  JIEO  is  also 
responsible  for  NATO  Standardization  Agreements  (STANAGs)  and 
their  implementation  by  the  U.S.,  including  STANAG  4214 
(STANAG  4214,  1985),  which  deals  with  international  telephone 
call  routing  and  directories  for  tactical  communications. 

STANAG  4214  was  developed  to  allow  international  routing 
between  highly  mobile  tactical  area  telephone  networlcs.  The 
requirement  for  STANAG  4214  was  established  when  it  was 
recognized  that  units  would  be  continually  relocating,  and 
that  international  forces  would  be  distributed  throughout  the 
command  structure.  To  properly  route  telephone  calls,  a 
system  had  to  be  developed  that  would  allow  unique 
identification  of  each  unit  (formation) .  The  protocol  set 
forth  in  STANAG  4214  was  designed  to  meet  this  requirement. 

Unfortunately,  several  nations  have  had  difficulty  in 
interpreting  STANAG  4214.  These  difficulties  resulted  in 
various  attempts  by  some  of  these  countries  to  analyze  the 
effectiveness  of  STANAG  4214,  all  of  which  were  unsuccessful. 
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These  failed  analyses,  combined  with  results  of  international 
training  exercises  which  revealed  that  the  STANAG  4214 
protocol  had  not  been  adequately  tested,  left  JIEO  with 
serious  concerns  about  the  validity  of  the  protocol.  There 
were  also  concerns  about  the  strict  limitation  of  inter-unit 
connections  which  could  be  established  under  STANAG  4214 
protocol.  As  a  result  of  these  concerns,  JIEO  requested  the 
Operations  Research  Department,  Naval  Postgraduate  School, 
Monterey,  Ca,  to  evaluate  the  STANAG  4214  protocol  methodology 
and  to  develop  rules  which  would  allow  for  more  lenient 
guidelines  on  the  establishment  of  inter-unit  connections. 
JIEO  also  requested  rules  to  ensure  calls  within  a  system 
utilizing  STANAG  4214  protocol  would  not  be  handled  more  than 
once  by  any  unit . 

To  meet  these  objectives,  an  object-oriented  computer 
simulation  model  called  TACFONE-NATO  was  developed.  The  model 
is  menu  driven  with  both  graphical  and  hard  copy  output . 
TACFONE-NATO  incorporates  all  the  original  STANAG  4214 
protocol  and  allows  the  option  of  implementing  several 
modifications  that  improve  survivability  of  the  area 
communication  networks  and  the  overall  effectiveness  the 
STANAG  4214.  TACFONE-NATO,  in  conjunction  with  a  mathematical 
program,  was  used  to  analyze  the  effectiveness  of  the  STANAG 
4214  protocol,  isolate  discrepancies  in  the  protocol,  and  to 
develop  and  test  the  rules  requested  by  JIEO. 
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The  analysis  revealed  one  discrepancy  in  the  current 
protocol  which  can  be  remedied  through  a  change  in  STANAG 
4214.  The  analysis  also  verified  the  need  for  rules  which 
ensure  that  calls  within  a  system  are  not  handled  more  than 
once  by  any  unit.  Additionally,  by  using  the  model's  ability 
to  verify  modifications  to  the  STANAG  4214  protocol,  rules 
were  successfully  developed  which  ensure  no  multiple  handling 
of  calls  by  any  unit  and  also  allow  for  more  leniency  on  the 
establishment  of  inter-unit  connections.  These  rules  improved 
STANAG  call  completion  rate  from  a  potential  low  of  under  70 
percent  (without  rules  to  ensure  multiple  handling  of  calls  by 
any  units)  to  100  percent,  while  simultaneously  easing  the 
restrictions  on  inter-unit  connections. 

TACFONE-NATO  will  be  a  powerful  tool  used  at  JIEO  and 
other  NATO  facilities.  TACFONE-NATO  will  allow  Communication 
System  Network  Managers  of  international  forces  to  quickly 
obtain  all  information  required  to  number  a  Communication 
System  in  accordance  with  STANAG  4214  protocol  and  to 
thoroughly  test  a  proposed  communication  system  before  assets 
are  dedicated  to  it. 
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I.  INTRODUCTION 


The  Joint  Interoperability  Engineering  Organization  (JIEO) 
is  responsible  for  ensuring  interoperability  of  communication 
systems  with  United  States  allies,  including  North  Atlantic 
Treaty  Organization  (NATO)  allies.  JIEO  is  also  responsible 
for  NATO  Standardization  Agreements  (STANAGs)  and  their 
implementation  by  the  U.S.,  including  STANAG  4214  (STANAG 
4214,  1985) ,  which  deals  with  international  telephone  call 
routing  and  directories  for  tactical  communications. 

STANAG  4214  was  developed  to  allow  international  routing 
between  mobile  tactical  area  telephone  networks.  The  need  for 
STANAG  4214  was  established  when  it  was  recognized  that  units 
would  be  not  only  be  relocated,  but  also  would  be  re¬ 
distributed  throughout  the  command  structure  including 
attachment  to  other  nation's  commands.  In  order  to  properly 
route  telephone  calls,  a  system  had  to  be  developed  that  would 
allow  unique  identification  of  each  unit (formation)  within 
mixed  national  structures. 

The  result  was  the  International  Routing  and  Directory 
rules  that  are  defined  in  STANAG  4214.  Several  nations, 
including  the  United  States,  have  implemented  the  rules  and 
procedures  defined  in  the  STANAG  4214.  In  1987,  Norway  began 
the  development  of  their  Digital  NATO  Interface  for  tactical 
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telephone  communication  systems.  In  their  attempts  to 
implement  STANAG  4214,  they  had  considerable  difficulty 
interpreting  the  document.  Several  years  were  spent 
addressing  the  sections  of  the  STANAG  that  could  be 
potentially  misconstrued.  The  United  States  held  the  position 
that  the  STANAG  4214  was  generally  clear,  but  the  issues 
brought  up  by  Norway  caused  some  concern  about  the  United 
States'  interpretation. 

JIEO  reviewed  the  results  of  international  training 
exercises  to  determine  if  there  had  been  any  problems 
encountered  with  the  actual  implementation  and  use  of  the 
STANAG  4214  protocol.  It  was  determined  from  the  results  of 
these  training  exercises  which  utilized  the  STANAG  4214 
protocol,  that  the  STANAG  4214  protocol  had  not  been  fully 
tested  and  validated. 

In  1991,  the  United  Kingdom  proposed  modifications  to  the 
STANAG  4214  that  would  enhance  area  communication  networks 
survivability.  These  proposed  changes  also  needed  to  be 
evaluated  to  determine  if  they  were  compatible  with  the 
current  STANAG  4214  protocol. 

At  this  point,  JIEO  determined  that  a  study  should  be 
pursed  to  determine  the  actual  effectiveness  of  the  STANAG 
4214  protocol  and  the  proposed  changer.  It  would  be  difficult 
to  determine  the  actual  effectiveness  of  the  STANAG  4214 
protocol  thorough  operational  testing  due  to  the  size  of 
communication  system  that  it  is  designed  to  address;  such  a 
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system  would  only  exist  if  a  major  multi-national  NATO  force 
were  mobilized  to  meet  some  real  threat.  The  cost  of 
establishing  such  a  communication  system  for  a  one-time  test 
would  be  prohibitive  and  would  require  member  nations  to  use 
equipment  that  is  currently  utilized  elsewhere.  Furthermore, 
a  complete  and  thorough  testing  of  the  rules  would  require 
numerous  setups  of  various  configurations.  It  would  be 
extremely  expensive  in  both  time  and  assets. 

A  more  cost  effective  method  of  evaluating  the  STANAG  4214 
protocol  methodology  and  proposed  changes  is  computer 
simulation.  A  simulation  model  called  TACFONE-NATO,  was 
developed  for  this  purpose.  It  is  written  in  the  object- 
oriented  simulation  language  MODSIM  (MODSIM  93)  .  Object- 
oriented  simulation  means  that  modular  blocks  are  used  to 
emulate  certain  actions  of  physical  things,  these  blocks  of 
code  are  grouped  together  into  an  "object"  which  inherits  the 
ability  to  perform  these  actions.  The  "object"  also  contains 
whatever  information  is  required  to  carry  out  these  actions. 
Object-oriented  simulation  was  used  to  simulate  the  crucial 
elements  of  the  communications  equipment  used  in  the  telephone 
networks  addressed  by  the  STANAG  4214.  The  use  of  an  object- 
oriented  language  made  it  much  easier  to  construct  an  accurate 
representation  of  reality  with  this  simulation.  The  model  is 
controlled  through  a  graphical  user  interface  (GUI)  and 
produces  both  graphical  and  hard  copy  output.  TACFONE-NATO 
incorporates  all  of  the  original  STANAG  4214  protocol  and 
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allows  the  option  of  implementing  several  modifications  that 
improve  survivability  of  the  area  communication  networks  and 
the  overall  effectiveness  of  STANAG  4214.  These  modifications 
developed  by  the  authors  will  be  discussed  later.  TACFONE- 
NATO  can  also  be  used  by  the  network  managers  to  produce  the 
numbering  scheme  for  a  network,  or  to  test  a  proposed 
numbering  scheme  that  does  not  completely  follow  the  STANAG 
4214  protocol. 

The  interpretation  of  STANAG  4214  protocol  used  in 
developing  TACFONE-NATO,  the  TACFONE-NATO  model  itself,  the 
proposed  changes  evaluated  and  the  results  of  the  evaluation 
will  be  discussed  in  the  following  sections.  The  goal  of  this 
thesis  is  to  develop  an  object-oriented  simulation  of  the 
STANAG  4214  protocol  with  potential  modifications,  to  analyze 
the  effectiveness  of  the  protocol  and  the  modifications,  and 
to  make  recommendations  based  on  this  analysis. 
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II.  STANDARDIZATION  AGREEMENT  (STANAG)  4214 


In  this  chapter  the  terms  necessary  to  discuss  the  STANAG 
4214  protocol  will  be  defined  to  allow  for  concise 
understanding.  The  aim  of  the  STANAG  4214  will  also  be 
presented.  As  previously  discussed,  there  has  been  difficulty 
in  interpreting  and  understanding  the  STANAG  4214  protocol, 
therefore  the  exact  interpretation  used  in  developing  TACFONE- 
NATO  will  also  be  discussed  in  depth  in  this  chapter. 

A.  TERM  DEFINITIONS 

All  the  terms  defined  below  are  in  the  context  of  the 
STANAG  4214.  The  definitions  may  not  follow  conventional 
meanings,  but  allow  for  concise  understanding  in  the  context 
of  this  discussion. 

1 .  Formations 

Any  military  unit  that  is  connected  in  a  communication 
system,  as  discussed  below,  is  considered  a  formation.  All 
formations  are  capable  of  sending  and  receiving  calls  as  well 
as  forwarding  calls  to  other  formations.  Each  formation  may 
have  numerous  telephones  within  its  system  but  is  considered 
a  single  unit  because  all  calls  are  routed  through  a  central 
communications  terminal .  A  formation  is  considered  under 
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command  of  another  formation  if  its  external  communication 
needs  are  served  by  that  formation. 

a.  Networks 

Formations  are  connected  into  hierarchial  tree 
structures  called  networks,  see  Figure  1. 

b.  Moat  Formations 

The  root  of  the  network  tree  is  called  the  Host 
Formation,  see  Figure  2.  All  formations  in  the  network  are 
served  by  the  Host  Formation's  communication  system  and 
therefore  are  under  "command"  (as  discussed  earlier)  of  the 
Host  Formation.  This  communications  setup  may  or  may  not 
reflect  actual  operational  or  administrative  chains  of 
command . 

c.  Primary  and  Secondary  Formations 

The  formations  directly  beneath  the  Host  Formation 
in  the  network  with  a  direct  connection  to  the  Host  are 
considered  formations  under  command  and  are  called  Primary 
Formations.  The  formations  beneath  the  Primary  Formations  are 
called  Secondary  Formations,  see  Figure  2. 

d.  Communication  Systems 

A  group  of  networks  connected  together  at  the  Host 
Formation  level  comprise  what  is  called  a  Communication  System 
(CommSys) ,  see  Figure  3. 
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Figure  2  Levels  of  a  communication  network. 
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Figure  3 


A  communication  system. 
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2 .  Connections 


a .  Trunks 

The  line  between  the  formations  in  the  Figure  4 
represents  the  physical  connection  or  trunks  between  the 
formations.  The  connection  can  be  cable,  radio  link, 
satellite  link,  or  other  communication  links  utilized  by  NATO 
member  nations. 

b.  Switches 

The  switch  is  the  physical  connection  point  between 
a  formation  and  a  trunk,  see  Figure  4.  There  is  a  separate 
switch  for  each  trunk  that  connects  the  formation  to  another 
formation.  Each  sv^itch  contains  a  routing  table  that  lists 
the  formations  that  can  be  reached  via  that  trunk.  The 
routing  table  does  not  necessarily  reflect  the  physical 
connections,  but  rather  the  formations  that  calls  are  allowed 
to  be  routed  through.  By  controlling  the  routing  table  lists, 
the  STANAG  4214  protocol  can  be  implemented  as  written  as  well 
as  with  the  modifications  that  will  be  discussed  in  later 
sections . 

c.  Gateways 

If  a  trunk  connects  formations  from  different 
countries,  the  switches  on  each  end  will  contain  a  gateway, 
see  Figure  4.  The  gateway  converts  outgoing  calls  from  the 
formation's  national  format  to  standard  NATO  format,  and  from 
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Figure  4  Trunk,  Gateway,  and  Switch. 


NATO  format  to  the  appropriate  national  format  for  incoming 
calls,  see  Figure  4. 

3.  The  Routing  Prefix 

Calls  are  routed  based  on  a  thirteen  digit  number  in 
NATO  tactical  systems  as  opposed  to  the  ten  digit  system  used 
in  the  United  States'  commercial  telephones.  The  number 
consists  of  a  six  digit  routing  prefix  and  seven  digit  local 
routing  number.  STANAG  4214  addresses  the  six  digit  routing 
prefix  only.  The  routing  prefix  is  assigned  to  each 
formation.  It  consists  of  two  parts,  see  Figure  5: 


1.  The  first  three  digits  are  the  National  Indicator  (NT), 
a  three-digit  code  that  indicates  the  country  the  formation 
belongs  to.  The  STANAG  4214  delineates  a  NI  for  each 
nation,  one  for  the  NATO  Tactical  Communication  System  and 
two  spares; 

2.  The  remaining  three  digits  are  the  Area  Code  (AC),  a 
three-digit  code  determined  from  the  communications  system 
topology,  the  equipment  available  at  the  formation,  the 
formation's  parent  and  its  Host. 


The  routing  prefix  is  often  called  a  NIAC,  see 
Appendix  A  for  the  complete  listing  form  the  STANAG  of  the  ACs 
and  NIs  (STANAG  4214, p.B-1-2, 1985)  .  Calls  are  routed  between 
networlcs  using  only  the  AC.  Within  a  particular  networJc 
routing  of  calls  is  based  on  the  entire  NIAC  to  allow 
decentralized  numbering  within  national  systems.  The  seven 
digit  local  routing  number  is  only  used  within  the  destination 
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formation,  to  route  a  call  to 
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the  particular  subscriber 
being  called. 


Figure  5  Routing  number. 


4.  Calls 

A  transmission  generated  from  one  formation  to  another 
is  referred  to  as  a  call.  A  call  can  be  a  normal  phone  call, 
a  modem  call  from  one  computer  to  another,  or  various  other 
types  of  communications  that  can  be  completed  over  telephone 
systems.  All  formations  under  command  (all  except  Host 
formations)  must  route  their  outgoing  calls  via  the  formation 
they  are  under  command  of  (their  parent) ,  unless  the 
destination  unit  is  a  formation  under  their  command  (one  of 
their  children)  .  A  call  made  within  a  networJc  is  routed 
upward  until  it  reaches  a  formation  that  is  the  parent  or 
grandparent  of  the  destination  formation.  It  then  is  routed 
downward  to  the  destination  formation  which  receives  the  call 
and  routes  it  to  the  particular  seven  digit  local  routing 
number.  A  call  for  a  formation  in  another  networlc  will  be 
routed  up  to  the  Host  formation  and  then  to  the  Host  formation 
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of  the  destination  formation  via  other  Host  formation (s)  if 
necessary.  It  is  then  routed  dovmward  until  it  reaches  the 
destination  formation  and  is  routed  internally  as  previously 
discussed. 

An  example  of  a  typical  call  within  a  network  follows. 
A  person  utilizing  a  telephone  in  a  Secondary  formation's 
system  calls  a  phone  number  in  a  Secondary  formation  that  has 
a  different  Primary  formation  as  it's  parent,  see  Figure  6. 
The  originator's  formation  system  determines  which  switch  to 
route  the  call  through  by  looking  at  the  switches'  routing 
tables  for  the  destination  formation's  NIAC.  In  this  case 
there  is  only  one  route  to  the  originator's  parent.  The  call 
is  then  routed  through  that  switch  and  the  trunk  connected  to 
it.  The  call  goes  through  the  switch  at  the  parent's  end  of 
the  trunk  and  the  parent  formation's  system  routes  the  call 
through  yet  another  switch  to  the  Host .  The  Host  routes  the 
call  through  the  switch  and  trunk  connecting  him  to  the  parent 
of  the  destination  formation,  a  Primary  formation  in  this 
case.  That  Primary  formation  then  routes  the  call  via  the 
switch  containing  the  number  for  the  destination,  and  the  call 
is  received  by  the  destination  formation's  system.  Finally, 
the  call  is  routed  to  the  phone  with  the  appropriate  seven 
digit  local  routing  number. 

A  call  to  a  formation  in  another  formation  is 
different  in  the  following  ways: 
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Figure  6  Call  internal  to  network. 
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1.  Once  the  call  reaches  the  originator's  Host,  the  Host 
system  determines  which  switch's  routing  table 
contains  the  destination  formation  AC  and  routes  it 
through  that  switch. 

2.  The  call  is  routed  through  different  Host  formation's 
system  until  it  reaches  the  Host  of  the  Destination 
formation. 

The  call  is  then  handled  as  discussed  in  the  previous  example, 
see  Figure  7 . 

5.  Equipment  Capabilities 

Two  equipment  capabilities  that  are  pertinent  to 
formation  numbering  are: 

1.  Whether  the  formation  is  multiple  or  single-routing 
capable; 

2.  Whether  the  formation  is  duplicate -capable  or  not. 

These  are  discussed  in  the  paragraphs  that  follow, 
a.  Multiple  or  Single  Routing-Capable 

Equipment  is  multiple-routing  capable  if  it  can 
route  a  call  to  another  formation  via  multiple  paths 
simultaneously.  Once  the  call  is  successfully  completed  along 
any  of  these  paths,  all  other  attempts  to  route  the  call  along 
alternate  paths  are  terminated.  Since  every  subscriber's 
seven  digit  number  is  unique  for  each  country,  this  allows 
several  formations  under  a  multiple -routing  formation  to  have 
the  same  NIAC.  A  call  will  fail  only  if  all  paths  attempted 
are  incorrect  (not  leading  to  the  destination) .  On  the  other 
hand,  equipment  that  is  single-routing  capable  can  only  route 
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a  call  via  one  path.  A  call  routed  by  it  through  an  incorrect 
path  will  always  be  a  failed  call.  Therefore,  all  single¬ 
routing  capable  Hosts  or  primary  formations  require  all 
formations  below  them  to  have  unique  NIACs. 

b.  Duplicate  Capable 

Equipment  that  is  duplicate  capable  is  able  to 
route  a  call  to  another  formation  with  the  same  routing  prefix 
(NIAC)  as  its  own,  while  not -duplicate -capable  equipment 
cannot.  Since  the  NI  for  all  formations  from  one  country  is 
the  same,  formations  which  are  not  duplicate  capable  require 
all  other  formations  from  their  nation  to  have  unique  area 
codes  (ACs) . 


B.  AIM  OF  STANAG  4214 

The  stated  aim  of  the  STANAG  4214  is: 

To  specify  the  routing  prefixes  and  their  application  in 
order  to  route  calls  from  one  tactical  communications 
network  to  another  one,  from  one  network  to  the 
communications  network  or  facilities  of  a  unit  under 
command  or  vice  versa,  and  even  from  one  communications 
network  via  that  of  a  unit  under  command  to  the 
communications  network  or  facilities  of  a  unit  under 
command  of  a  unit  under  command  (STANAG  4214,  1985) . 


STANAG  4214  also  sets  forth  protocol  for  strategic  network 
interface  numbering,  which  is  not  addressed  by  this  study. 

1.  Requirements  for  Area  Codes 

As  stated,  the  main  aim  of  STANAG  4214  is  to  address 
how  to  allocate  ACs  to  formations.  There  are  100  total  ACs  to 
be  allocated  among  the  NATO  tactical  communication  systems. 
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Area  Codes  are  assigned  to  networks  in  such  a  manner  that  all 
ACs  within  any  individual  network  are  different  from  all  ACs 
in  all  other  networks  within  the  communication  system.  This 
allows  the  routing  of  calls  to  be  based  primarily  on  the  AC 
only.  Each  network  has  a  set  of  unique  ACs  to  assign  to  the 
formations  within  it.  Therefore,  each  network  will  be  able  to 
determine  which  calls  are  for  it's  formations  based  only  on 
the  AC. 

2 .  Determination  of  Area  Codes 

The  determination  of  ACs  is  trivial  if  all  formations 
are  multiple  routing  and  duplicate  capable.  In  this  case,  a 
single  unique  area  code  for  each  network  is  all  that  is 
required.  However,  not  all  nations'  communications  equipment 
have  these  capabilities.  Because  of  this,  the  STANAG  4214 
rules  must  address  all  possible  combinations  of  equipment 
capabilities.  With  this  in  mind,  the  authors  of  STANAG  4214 
worked  towards  the  following  goals(STANAG  4214,  1985): 

1.  Simplify  and  reduce  the  amount  of  information,  in 
particular  ACs,  held  at  the  switches,  and  to  enable 
routing  on  ACs  alone  between  networks; 

2.  Reduce  the  amount  of  information  passed  across 
networks  when  formation  information  changes; 

3.  Make  ACs  as  deducible  as  possible,  enabling  someone  to 
determine  the  AC  of  a  formation  based  on  minimal 
information  of  the  formation's  actual  position  in  the 
communication  system; 

4.  Standardize  the  information  passed  across 
international  gateways. 
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C.  STANAG  4214  PROTOCOL  INTERPRETATIONS 


All  ACs  for  a  network  are  assigned  from  the  Host  nation's 
list  of  allocated  Area  Codes,  TACFONE-NATO  ignores  the  problem 
of  exceeding  the  ACs  of  any  particular  nation  as  suggested  by 
JIEO.  The  number  of  ACs  assigned  to  a  network  is  based  on  the 
communications  equipment  capabilities  of  the  Host  and  other 
formations  in  the  network.  If  a  formation  is  from  the  same 
nation  as  it's  parent,  it  will  receive  the  AC  of  its  parent 
regardless  of  communications  capabilities.  If  a  formation's 
equipment  is  not  duplicate  capable,  each  formation  from  that 
nation  within  the  network  must  receive  a  unique  AC  (unless 
there  are  parent/child  relationships  as  just  discussed) .  The 
additional  rules  which  follow  apply  only  to  duplicate  capable 
formations  with  a  different  nationality  than  their  parent 
and/or  their  Hosts. 

1 .  Host  Formations 

All  Host  formations  are  assigned  a  Master  Area  Code 
that  corresponds  to  nine  minus  the  formation's  corps  number 
followed  by  the  last  two  digits  of  the  formation's  NI .  For 
example,  the  United  States  Fourth  Corps  would  be  assigned  an 
AC  of  514  -  five  (nine  minus  four)  followed  by  14 (the  last  two 
digits  of  the  United  States  NI  of  914) . 

2.  Single-Routing  Capable  Hosts 

Host  formations  that  are  single -routing  capable 
require  unique  routing  prefixes  (NIACs)  for  all  Primary  and 
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Secondary  formations  that  may  foreseeablely  be  assigned  to 
them.  Thus,  if  there  are  several  formations  from  the  same 
country  within  the  network,  they  must  all  receive  distinct 
ACs.  Therefore,  the  required  number  of  subsidiary  ACs  (area 
codes  available  to  formations  assigned  to  a  Host  in  addition 
to  the  Master  Area  Code)  is  the  maximum  number  of  formations 
from  any  one  foreign  nation  assigned  to  the  network  minus  one. 
The  example  shown  in  Figure  8  would  require  the  Host's  master 
AC  and  three  subsidiary  ACs  for  a  total  of  four  because  the 
NIACs  will  uniquely  identify  all  formations  within  the 
network . 

3 .  Multiple  Routing  Capable  Hosts 

Multiple  routing  capable  Hosts  only  require  subsidiary 
ACs  if  there  are  Primary  formations  within  the  network  that 
are  single-routing  capable  or  if  there  is  more  than  one 
formation  from  a  nation  whose  equipment  is  not  duplicate- 
capable.  The  example  shown  in  Figure  9  would  require  the 
Host's  master  AC  and  two  subsidiary  ACs  for  a  total  of  three. 

4.  Primary  Formations  Under  Multiple  Router  Hosts 

Primary  formations  under  multiple-router  Hosts  are 

assigned  the  Host's  master  area  code.  The  only  exception  to 
this  rule  is  when  there  are  Primary  formations  whose 
communications  equipment  is  not  dupl icate- capable .  In  this 
case,  the  first  formation  from  a  nation  is  assigned  the  Host's 
master  AC  and  any  additional  formations  from  that  nation  are 


Figure  9  Multiple-routing  capable  Host  with  a  single-router 
Primary. 
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assigned  distinct  ACs.  The  example  in  Figure  10  shows  a 
network  with  a  multiple-router  Host  with  all  duplicate -capable 
Primaries,  therefore,  requiring  only  the  master  AC.  The 
example  in  Figure  11  shows  a  network  with  a  multiple-router 
Host  with  two  Primaries  that  are  not  duplicate -capable  and 
from  the  same  country,  therefore,  requiring  the  Host's  master 
AC  and  one  subsidiary  AC. 

5.  Primary  Formations  Under  Single  Router  Hosts 

The  first  Primary  formation  from  each  nation  under  a 
single-router  Host  is  assigned  the  Host  formation's  master  AC. 
Additional  formations  from  the  same  nation  will  be  assigned 
unique  subsidiary  ACs  from  the  list  allocated  to  the  Host 
nation,  see  Figure  8  for  an  example. 

6.  Secondary  Formations 

Area  codes  for  Secondary  formations  are  dependent  on 
the  communications  equipment  characteristics  of  the  Host 
formation,  its  Primary  (topologically  parent)  formation  and 
the  formation  itself. 

a.  Host  Formation  and  Primary  Formation  are  Both 
Multiple  Routing  Capable 

A  Secondary  formation  with  its  Host  formation  and 
Primary  formation  both  multiple-routing  capable  is  assigned 
the  AC  of  its  Primary  formation,  see  Figure  12  for  an  example. 
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Figure  10  Multiple -routing  capable  Host  with  all  Primaries 
duplicate -capable . 
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Figure  11  Multiple-routing 
capable  Primaries. 
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Figure  12  Multiple-routing  Host  with  multiple-routing 


Primaries 
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b.  Host  Formation  and/or  Primairy  Formation  are  Single 
Routing  Capable 

A  Secondary  formation  whose  Host  is  multiple- 
routing  capable  but  whose  Primary  is  only  single-routing 
capable  must  receive  an  area  code  which  is  unique  from  all 
other  formations  of  the  same  nation  under  that  particular 
Primary.  As  previously  stated,  a  Secondary  formation  whose 
Host  formation  is  only  single-routing  capable  is  assigned  a 
unique  AC  from  all  other  formations  from  the  same  nation  in 
the  Host's  network,  see  Figure  rf. 

7 .  Other  Rules 

In  addition  to  the  above  listed  rules,  STANAG  4214 
also  directs  that  each  Host  formation  be  assigned  three 
subsidiary  ACs  regardless  of  the  formations  used  to  make  up 
the  network.  This  added  rule  is  not  reflected  by  the  TACFONE- 
NATO  model  because  the  numbering  method  created  for  TACFONE- 
NATO  determines  the  exact  number  of  subsidiary  ACs  needed  for 
each  network.  Also,  the  STANAG  protocol  allows  an  option 
whereby  a  single-router  Host  with  a  multiple-router  Primary 
may  assign  all  Secondary  formations  of  that  Primary  the  same 
AC  if  there  is  no  possibility  of  them  moving  up  to  the  Primary 
level.  In  authors'  view,  due  to  the  dynamic  force  structures 
involved  the  requirement  for  this  option  cannot  necessarily  be 
guaranteed,  so  this  option  was  not  considered  or  utilized  in 
this  study. 
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D.  SUMMARY 


The  terminology  introduced  in  this  chapter  will  allow  for 
more  concise  discussion  in  this  and  following  chapters.  The 
protocol  interpretation  presented  in  this  chapter  gives  a 
plain  language  version  of  the  complicated  set  of  rules  laid 
out  in  the  STANAG  4214.  As  can  be  seen  from  the  discussion  of 
the  protocol,  there  are  numerous  situations  that  can  arise  in 
the  configuration  of  communication  systems  and  therefore  an 
extensive  set  of  rules  is  required  to  cover  all  contingencies. 
The  complexity  of  the  rules  makes  the  task  of  modeling  the 
protocol  much  more  difficult,  as  will  be  discussed  in  the 
following  chapter. 
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HI.  MODELING  THE  NATO  COMMUNICATION  SYSTEM 


The  problem  of  modeling  the  NATO  communication  system  and 
the  process  generating  and  routing  all  possible  calls  is  very 
large  and  complex.  Because  the  system  is  composed  of 
independent  pieces  of  equipment  whose  functions  can  be 
emulated,  it  lends  itself  to  being  modeled  and  analyzed 
utilizing  an  object-oriented  simulation  language. 
Accordingly,  the  TACFONE-NATO  model  was  written  in  object- 
oriented  modeling  and  simulation  language  MODSIM  (MODSIM  93) . 
TACFONE-NATO  simulates  a  communication  system's  crucial 
elements  in  order  to  allow  the  implementation  of  the  STANAG 
4214  protocols.  The  entire  model  was  designed  to  represent 
the  physical  equipment  and  the  actual  process  of  sending  and 
receiving  calls,  but  only  at  the  level  of  fidelity  for  each 
element  that  was  required  for  this  study.  Therefore,  some 
elements  that  are  modeled  may  not  exactly  reflect  the  actual 
equipment  or  process  simulated,  but  for  the  purposes  of  the 
study  reflect  accurately  the  portion  that  affects  numbering 
formations  and  routing  calls.  The  model  is  completely 
supported  with  graphics,  which  promotes  ease  of  use  and 
simplifies  the  analysis  of  results. 
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A.  Basic  Model  Objects 

A  description  of  the  basic  building  blocks  of  TACFONE-NATO 
follows.  They  simulate  the  crucial  elements  of  a 
communication  system  that  are  required  to  evaluate  the  STANAG 
4214  protocol. 

1 .  Cosnmmlcation  System 

A  communication  system  consists  of  a  set  of  networks, 
inter-connected  only  through  their  Host  formations.  These 
interconnections  create  at  least  a  minimally  connected  graph 
of  all  networks  (Figure  13)  and  may  create  up  to  a  fully 
connected  graph  (Figure  14) . 

2 .  Networks 

A  network  is  a  hierarchically  constructed  tree  of 
formations  with  a  maximum  of  three  levels,  this  is  the  maximum 
number  of  levels  the  STANAG  4214  protocol  addresses.  The  only 
connections  allowed  between  formations  in  a  network  are  the 
ones  that  follow  this  tree  structure.  Therefore,  the 
Secondary  formations  only  have  one  connection,  with  their 
parent  (Primary)  formation.  The  Primary  formations  have  one 
connection  with  each  of  their  children  (Secondaries)  and  one 
connection  with  their  Host  formation.  Each  Host  formation  has 
one  connection  with  each  of  his  child  Primary  formations  and 
connections  to  other  Host  formations,  depending  on  the 
topology  of  the  communication  system. 
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Figure  13  Minimally  connected  graph. 
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Figure  14  Fully  connected  graph. 


3 .  Formations 


The  formations  represent  the  communication  systems  of 
different  sized  military  units.  Generally,  Host  level 
formations  represent  Corps-sized  units,  Primary  level 
formations  equate  to  division-sized  units  and  Secondary  level 
formations  represent  brigade-sized  units.  The  STANAG  4214 
protocol  does  not  address  units  of  any  smaller  size, 
therefore,  TACFONE-NATO  does  not  represent  any  other  unit 
types . 

4.  Switches,  Trxinks  and  Gateways 

The  function  of  gateways  are  not  crucial  to  the 
routing  protocol  addressed  by  STANAG  4214  and  therefore  are 
not  modeled.  The  switches  and  trunks  are  modeled  to  reflect 
previously  discussed  definitions.  The  switches  are  the 
connection  between  the  formation  and  the  trunk  and  contain  the 
routing  information  for  that  path  from/to  the  formation.  The 
trunk  connects  two  formations  and  routes  calls  between  them. 

B.  NUMBERING  THE  COMMUNICATIONS  SYSTEM 

The  model  numbers  the  Communication  System  according  to 
the  rules  of  STANAG  4214  previously  discussed.  Each  formation 
numbers  itself,  by  determining  its  own,  its  parent's  and  its 
Host's  communication  equipment  capabilities  and  applying  the 
applicable  STANAG  4214  rule(s)  for  its  numbering. 
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C.  GENERATION  OP  COMMUNICATION  SYSTEMS 


TACFONE-NATO  will  either  read  in  a  user-defined  force 
structure  or  randomly  generate  a  force  structure.  If  the 
force  is  user-defined,  TACFONE-NATO  can  automatically  number 
the  communication  system  or  the  NIACs  can  be  defined  by  the 
user  and  analyzed  using  TACFONE-NATO.  This  gives  the  user  the 
flexibility  of  analyzing  a  proposed  numbering  scheme  that  does 
not  follow  the  STANAG  rules.  The  connections  between  networks 
at  the  Host  level  are  either  randomly  generated  by  TACFONE- 
NATO  or  defined  by  the  user.  When  the  communication  system  is 
generated  randomly,  the  number  of  networks,  formations  and 
connections  between  networks  are  all  randomly  determined  from 
preset  bounds.  The  identity  of  the  formations,  including 
nationality,  are  also  randomly  determined  from  the  existing 
units  that  are  available  to  NATO. 

The  units  available  from  NATO  are  determined  from  the 
table  in  the  STANAG  4214  (STANAG  4214,  p.  B-1-2,  1985),  see 
Appendix  A.  The  model  starts  with  this  force  allocation  as  it 
randomly  generates  a  force  structure  and  will  not  exceed  the 
number  of  Host  formations,  three  Primary  units  for  each  Host, 
and  three  Secondaries  for  each  Primary  listed  in  the  table. 
Once  the  force  has  been  generated  and  connected,  the 
formations  are  numbered  using  the  method  previously  discussed. 
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D.  BUILDING  ROUTING  TABLES 


Once  the  communication  system  is  generated  and  has  been 
numbered,  the  routing  tables  are  initialized  for  each  trunk  of 
each  formation.  Each  network  first  updates  its  routing  tables 
internally,  then  the  switches  connecting  the  networks 
initialize  their  routing  tables.  The  basic  model  cllows  all 
paths  that  exist  from  one  network  to  another  to  be  reflected 
in  the  routing  tables.  STANAG  4214  does  not  directly  address 
what  paths  should  exist  from  one  network  to  another,  only  that 
it  is  done  in  a  way  "to  prevent  looping"  (STANAG  4214,  p.  c-2, 
1985) .  The  basic  model  operates  this  way  to  provide  the 
ability  to  measure  the  effectiveness  of  anti-looping  rules, 
some  of  which  will  be  discussed  below. 

E.  GENERATING  AND  ROUTING  CALLS 

Calls  are  generated  from  every  formation  to  every  other 
formation.  The  formation  routes  a  call  based  on  the  physical 
limitations  of  the  communications  equipment  of  its  nation,  as 
well  as  the  contents  of  its  switches'  routing  tables.  Between 
networks,  calls  are  only  routed  via  one  path  (single -routed) . 
The  call  tracks  all  formations  that  it  is  routed  through  to 
reach  its  destination.  There  are  several  circumstances  where 
a  call  fails  to  reach  its  destination,  each  creating  a  unique 
diagnostic  problem.  These  circumstances  will  be  discussed 
later. 


36 


F.  GRAPHICS 


The  TACFONE-NATO  model  utilizes  the  SIMGRAPHICS  (MODSIM 
93)  portion  of  MODSIM  to  display  all  input  ar^d  output 
graphically.  The  model  is  controlled  through  mouse-driven 
graphical  user  interfaces  making  it  quite  user-friendly, 
compared  to  all  input  being  entered  through  the  keyboard.  The 
Communication  System  is  displayed  graphically  using  a  separate 
window  for  each  network.  Each  formation  is  displayed  as  a 
rectangle  enclosing  its  nationality,  unit  size  (corps, 
division,  or  brigade) ,  unit  number,  and  NIAC.  Trunks  are 
represented  as  lines  between  formations, see  Figure  15  for  an 
example  of  a  network  representation.  The  set  of  Host 
formations  are  also  displayed  in  a  separate  window,  with 
inter-host  connections  displayed  as  lines,  see  Figure  16.  As 
each  call  is  routed,  the  originator  formation,  the  destination 
formation,  and  all  trunks  in  the  path  are  colored  to  allow  the 
user  to  visually  watch  the  calls  progress.  The  display  is 
frozen  when  a  call  fails,  which  aids  in  trouble  shooting 
protocol  problems. 

G.  SUMMARY 

TACFONE-NATO  as  presented  in  this  chapter  is  an  object- 
oriented  computer  model  which  simulates  the  STANAG  4214 
protocol,  calls,  and  all  equipment  required  to  effectively 
evaluate  the  protocol.  The  model  is  GUI  driven  and  user- 
friendly.  Complete  instructions  and  more  extensive 
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Figure  16  Communication  system  representation. 


39 


explanations  of  the  use  of  the  model  is  given  in  the  user's 
manual  in  Appendix  B. 
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IV.  CAPABILITIES  ADDED  TO  THE  BASIC  MODEL 


JIEO  was  very  interested  in  the  development  of  anti- 
looping  rules  and  in  exploring  the  effects  of  allowing  lateral 
connections .  In  this  chapter  these  critical  issues  will  be 
defined  and  some  proposed  techniques  for  dealing  them  will  be 
discussed. 

A.  Anti -Looping 

STANAG  4214  explicitly  states  that  routing  tables  between 
the  Host  formations  must  "not  allow  loops  to  exist"  (STANAG 
4214,  p.  C-2,  1985  ) .  A  loop  occurs  when  a  call  arrives  at  a 
formation  which  has  already  handled  it.  Figure  17  depicts 
routing  tables  which  provide  the  possibility  of  a  loop.  Here, 
Host  five  initiates  a  call  to  Host  one,  selecting  to  route  the 
call  through  Host  three,  who  in  turn  routes  it  through  Host 
two.  At  this  point.  Host  two's  routing  tables  allow  him  to 
either  route  the  call  to  Host  one  or  through  Host  five.  If 
the  route  through  Host  five  is  selected,  a  loop  occurs  since 
Host  five  has  already  handled  the  call.  The  bold  path  in 
Figure  17  illustrates  this  occurrence.  While  the  STANAG 
states  not  to  allow  loops,  it  does  not  provide  any  methods  of 
doing  so.  Here,  rules  are  developed  for  building  routing 
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Figure  17  A  looped  call. 
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tables  between  Host  formations  which  ensure  that  looped  calls 
are  not  possible. 

1.  Objectives  of  the  Rules 

A  simple  solution  to  the  problem  would  be  to  build  the 
routing  tables  such  that  there  was  only  one  path  from  each 
Host  to  all  others.  While  this  would  certainly  avoid  looping, 
it  is  not  particularly  desirable  because  it  removes  all 
possible  redundancy  which  the  physical  system  may  be  able  to 
support.  Of  course,  the  more  redundancy  allowed,  the  greater 
the  potential  for  creating  the  possibility  of  a  loop.  In 
light  of  this,  rules  were  sought  to  build  routing  tables  such 
that : 

1.  There  exists  at  least  one  path  from  each  Host  to  every 
other  Host . 

2 .  There  is  no  potential  for  a  looped  call . 

3.  Maximum  redundancy  is  achieved  under  the  following 
constraints : 

a.  Maximize  the  minimum  number  of  switches  through  which 
a  Host  can  route  to  any  other  Host.  That  is,  for  a  six 
Host  Communication  System,  it  is  preferred  for  a  Host  to 
be  able  to  route  to  all  other  Hcots  through  two  switches 
rather  than  to  be  able  to  route  to  three  Hosts  through 
five  switches,  but  to  the  other  two  through  only  one. 
The  goal  is  to  "spread  the  wealth"  for  redundancy. 

b.  Shorter  paths  are  sought  for  redundancy  before  longer 
ones.  That  is,  it  is  more  desirable  to  have  a  three  step 
path  than  a  four  step  path  between  two  Hosts . 


43 


2.  Proposed  Solution  Techniques 

a.  Complete  Snumeration 

Since  the  number  of  Hosts  being  dealt  with  was 
fairly  small  (a  maximum  of  six) ,  an  attempt  was  made  to  fully 
enumerate  the  various  combinations  of  routing  tables  possible 
and  compare  them.  To  ensure  this  would  be  feasible  for  all 
Communication  Systems  which  could  be  constructed  with  six  or 
fewer  Hosts,  the  worst -case  scenario  of  having  six  Hosts,  each 
connected  to  every  other  Host  was  considered.  In  this 
situation  there  are  a  total  of  30  routing  tables  to  fill,  each 
of  which  may  contain  any  or  all  of  five  different  numbers. 
Assuming  that  each  routing  table  will  contain  the  Host  number 
to  which  it  is  connected,  four  spaces  are  left  in  each  routing 
table  which  may  or  may  not  contain  a  number.  With  a  total  of 
30  tables,  this  leaves  120  unique  spaces  with  a  go/no-go 
decision  as  to  whether  to  or  not  to  put  in  a  number.  This 
results  in  a  total  of  (equals  approximately  1.33  x  10^®) 

possible  routing  table  combinations.  If  it  were  possible  to 
fully  examine  one  trillion  of  these  possibilities  every 
second,  it  would  take  over  four  hundred  trillion  years  to 
examine  each  possible  combination  of  routing  tables.  This  is 
obviously  infeasible. 

b.  Anti-Looping  Heuristic 

Since  it  is  infeasible  to  fully  enumerate  all 
possible  routing  table  combinations  for  all  Communication 
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Systems  which  could  be  constructed,  and  because  the  problem 
does  not  formulate  neatly  as  an  optimal -solved  mathematical 
program,  a  heuristic  was  developed  to  meet  the  previously 
stated  goals.  The  steps  of  the  heuristic  are: 

1.  For  each  Host  switch  which  connects  to  another  Host, 
enumerate  all  possible  non-looping  paths  to  all  other  Hosts 
based  on  the  physical  structure  of  the  inter -host 
connections  (an  inter-host  connection  is  a  connection 
between  two  different  Hosts) . 

2 .  For  each  inter-host  switch,  add  the  connected  Host  to 
that  switch's  routing  table. 

3.  Start  with  any  inter-host  switch.  From  all  possible 
two-step  paths,  choose  the  one  whose  destination  is  in  the 
fewest  routing  tables  of  the  switch's  formation.  If  a  tie 
exists,  randomly  select  from  those  tied.  If  no  two  step 
path  exists,  move  on  to  step  (5) . 

4.  Check  to  see  if  adding  this  destination  to  the  switch's 
routing  table  will  cause  a  loop  based  on  the  destinations 
currently  in  'll  the  other  inter-host  switches'  routing 
tables.  If  not,  add  the  destination  to  the  switch's 
routing  table.  If  it  does  cause  a  loop,  remove  this  path 
from  all  possible  two  step  paths  and  repeat  step  (3) . 

5.  Repeat  steps  3-4  for  each  inter-host  switch. 

6.  Repeat  steps  3-5  until  all  possible  two  step  paths 
have  been  examined  to  see  if  they  cause  a  loop. 

7.  Repeat  steps  3-6  for  all  possible  three  step  paths, 
then  for  all  possible  four  step  paths,...,  and  finally  for 
all  possible  (n-l)  step  paths;  where  n  is  the  number  of 
Hosts  in  the  Communications  System. 


NOTE:  When  conducting  step  (3)  for  paths  of  three  or  more 
steps,  ignore  all  paths  whose  destination  is  already  in  the 
switch's  routing  table. 

Only  paths  of  length  (n-l)  or  shorter  need  be 

examined  since  any  longer  path  would  necessarily  form  a  loop. 

Checking  all  paths  up  to  length  (n-l)  ensures  that  in  the 
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worst  case  of  only  a  (n-l)  step  path  existing  between  two 
Hosts,  they  will  still  be  able  to  reach  each  other.  In  fact, 
a  more  in-depth  check  of  this  algorithm  shows  that,  assuming 
at  least  a  minimum  spanning  tree  is  formed  by  the  inter-host 
connections,  each  Host  will  be  able  to  reach  every  other  Host. 
This  can  be  shown  by  assuming  Host  j  cannot  reach  Host  k  with 
at  least  one  non-looping  path.  This  would  imply  that  none  of 
the  Hosts  connected  to  Host  j  could  reach  Host  k  with  a  non¬ 
looping  path,  since  if  one  could,  a  non- looping  path  from  j 
could  be  formed  by  adding  the  link  from  j  to  the  Host  which 
could  reach  k.  By  inductively  continuing  in  this  manner,  it 
can  be  shown  that  if  Host  j  cannot  reach  Host  k  by  a  non- 
looping  path,  then  no  Host  in  the  Communication  System  can. 
But  this  is  not  possible  since  k  is  connected  to  a  least  one 
other  Host  in  the  Communication  System.  Therefore,  it  is  not 
possible  for  Host  j  not  to  be  able  to  reach  Host  k  with  at 
least  one  non- looping  path.  Since  this  applies  to  any  two 
Hosts,  each  Host  will  be  able  to  reach  every  other  Host. 

It  is  also  clear  that  this  heuristic  ensures 
that  no  loops  will  exist  since  this  is  checked  prior  to  adding 
any  number  to  a  routing  table.  Furthermore,  the  selection 
process  in  step  (3)  of  the  heuristic  is  conducive  to 
maximizing  the  minimum  number  of  switches  through  which  a  Host 
can  route  to  any  other  Host.  The  iterative  process  of 
checking  for  the  smallest -step  paths  first  also  contributes  to 
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including  shorter  paths  before  longer  ones.  Thus,  the 
heuristic  promotes  all  of  the  stated  goals. 

B.  Lateral  Connections 

The  STANAG  4214  protocol  does  not  allow  for  connections 
between  units  other  than  parents  and  children  and  between 
Hosts.  Any  connection  established  between  units  other  than 
between  Hosts  or  between  a  parent  and  child  is  defined  as  a 
lateral  connection.  The  reason  STANAG  4214  does  not  allow 
lateral  connections  is  the  increased  risk  of  looped  calls. 
However,  units  not  connected  under  current  STANAG  4214 
protocol  may  be  in  close  physical  proximity,  and  it  may  be 
very  desirable  for  these  units  to  have  a  communications  link 
between  them  for  local  logistical  traffic.  The  current  STANAG 
4214  protocol  does  not  allow  for  such  a  link.  Here,  routing 
table  rules  are  developed  that  allow  for  lateral  connections 
to  be  established  without  resulting  in  possible  loops. 

1 .  Recommended  Rules 

Rules  were  desired  which  would  cover  any  possible 
lateral  connection.  That  is.  Primary  to  Primary,  Secondary  to 
Secondary,  Host  to  a  non-child  Primary,  Host  to  Secondary,  and 
Primary  to  a  non-child  Secondary.  Furthermore,  it  was  desired 
for  the  rules  to  work  whether  the  lateral  connection  existed 
between  formations  within  the  same  network  or  between 
formation  in  different  networks.  Additionally,  it  was 
undesirable  for  the  rules  to  in  any  way  restrict  the  number  of 
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lateral  connections  allowed  as  this  would  become  very 
confusing. 

The  rules  developed  to  meet  these  requirements  are  as 

follows ; 

1.  No  call  shall  be  allowed  to  route  downwards  in  a 
network's  hierarchical  structure  to  make  use  of  a  lateral 
connection. 

2.  No  call,  after  using  a  lateral  connection  shall  be 
allowed  to  route  upwards  in  a  network's  hierarchical 
structure . 

3.  No  call  shall  be  routed  through  more  than  one  lateral 
connection. 

In  TACFONE-NATO,  these  rules  are  enforced  through  the 
construction  of  the  routing  tables,  as  opposed  to  each  call 
tracking  its  use  of  lateral  connections.  Because  of  this,  if 
there  are  more  than  two  formations  from  any  nation  in  a 
network  which  are  numbered  the  same  (implies  that  the  Host  is 
multiple-routing  and  the  nation  is  duplicate-capable)  ,  and  anv 
two  of  these  are  laterally  connected,  the  above  rules  may  be 
violated.  However,  even  with  this  feasible  "breaking  of  the 
rules",  there  will  be  no  looping.  The  only  possibility  of 
looping  when  routing  tables  are  used  to  enforce  these  rules  is 
if  four  or  more  formations  from  a  single-routing  nation  are 
numbered  the  same  and  are  laterally  connected  in  such  a  manner 
as  to  allow  looping  via  the  lateral  connections  alone.  This 
means  that  for  there  to  be  a  problem  with  the  enforcement  of 
these  rules  through  routing  table  construction,  all  of  the 
following  must  occur: 
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1.  Multiple -routing  Host. 

2.  Pour  or  more  formations  from  a  single-routing, 
duplicate -capable  nation  in  the  network  be  numbered  the 
same . 

3.  The  existence  of  enough  lateral  connections  between 
these  formations  such  that  the  lateral  connections 
themselves  provide  the  possibility  of  a  loop. 

The  existence  of  this  unique  set  of  circumstances 
would  is  highly  improbable  and  would  rarely,  if  ever,  be 
realized  in  an  actual  Communication  System.  Therefore,  in  the 
opinion  of  the  authors,  enforcing  the  previously  stated  rules 
through  routing  table  construction  is  valid  for  all 
Communication  Systems  which  may  reasonably  be  assembled. 

These  rules  somewhat  localize  the  use  of  lateral 
connections,  but  this  is  not  unreasonable  since  it  is  likely 
that  the  main  purpose  for  establishing  a  lateral  connection 
would  be  for  local  traffic  between  two  formations  not 
otherwise  connected.  These  rules  do  prevent  looping  (with  the 
exception  of  the  improbable  unique  case  stated  above)  for  any 
ntimber  of  any  type  of  lateral  connections  and  also  provide  for 
maximum  additional  redundancy  without  putting  restrictions  on 
the  number  of  or  types  of  lateral  connections  allowed. 

C.  SUMMARY 

Two  of  the  issues  of  greatest  concern  to  JIEO  were  anti- 
looping  rules  and  the  effects  of  lateral  connections.  This 
chapter  presented  the  methods  used  to  develop  anti -looping 
rules  and  routing  table  rules  which  allow  for  lateral 
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connections.  TACFONE-NATO  always  implements  the  lateral 
connection  rules  (if  no  lateral  connections  exist  they  have  no 
impact)  and  allows  for  the  option  of  implementing  the  anti- 
looping  rules. 
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V.  DEDUCING  ERRORS  IN  THE  PROTOCOL 


The  heart  of  the  analysis  of  the  STANAG  4214  protocol  lies 
in  determining  the  overall  effectiveness  of  the  protocol  and 
in  detecting  and  isolating  errors  in  the  protocol.  This 
chapter  discusses  the  methodology  employed  to  accomplish  these 
tasks . 

A.  ANALYSIS  FOR  A  SINGLE  COMMUNICATIONS  SYSTEM 

The  basic  procedure  executed  by  TACFONE-NATO  is  as 
follows : 

1.  Construct  a  reasonable  force  composition  for  the 
operation,  choosing: 

a.  Country 

b.  Level  of  unit 

c.  Unit  capabilities 

2.  Construct  a  reasonable  NATO  chain  of  command  for  this 
force . 

3 .  Construct  a  reasonable  set  of  physical  connections 
between  pairs  of  units . 

4.  Assign  telephone  numbers  to  each  of  the  formations. 

5.  Construct  the  proper  routing  table  associated  with  each 
switch  in  each  formation. 

6 .  Attempt  a  call  from  each  formation  to  every  other 
formation,  recording  the  outcome. 

This  procedure  will  be  henceforth  known  as  a  single- system 

check.  Note  that  there  is  a  one-time  construction  of  the  NATO 
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force  structure,  and  one  assignment  of  nationality  for  each 
formation  in  a  single-system  check.  TACFONE-NATO  allows  for 
a  single  run  of  the  single-system  check  or  for  the  single¬ 
system  check  to  be  executed  over  and  over,  using  the  ability 
to  sample  random  variates  to  generate  different  force 
structures  and  nationalities  for  each  check. 

B.  ANALYSIS  OF  OVERALL  EFFECTIVENESS 

Determining  the  overall  effectiveness  of  the  STANAG  4214 
protocol  does  not  require  knowledge  of  how  many  potential 
failures  may  occur  in  the  protocol  under  various 
circumstances.  It  does  not  even  require  knowledge  of  what  the 
causes  of  any  failure  are.  This  is  because  the  number  and 
type  of  feasible  failures  does  not  take  into  account  the 
likelihood  that  situations  which  cause  these  failures  would 
actually  exist  in  a  communication  system.  Furthermore,  just 
because  a  path  exists  in  the  routing  tables  which  leads  to  a 
failure  does  not  mean  that  a  call  will  always  take  that  path. 
Indeed,  actual  calls  may  rarely  follow  paths  which  lead  to 
failures.  Because  of  this,  the  measure  of  effectiveness 
developed  for  the  STANAG  4214  protocol  was  the  mean  percentage 
of  successfully  completed  calls  when  each  formation  called 
every  other  formation  once  in  a  random  communication  system. 

To  determine  a  good  estimate  of  the  mean  percentage  of 
successfully  completed  calls  for  a  random  communication  system 
using  the  STANAG  protocol,  the  following  procedure  was  usecj: 
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1.  Generate  a  random  Communications  System 

2.  Make  a  good  estimate**  of  the  mean  number  of  successful 
call  for  that  communications  system  when  each  formation 
calls  every  other  formation  once,  with  each  call  following 
only  one  feasible  path  (when  more  than  one  feasible  path 
exists  randomly  choose  one  of  them) . 

3.  Record  the  estimated  mean  number  of  successful  calls. 

4.  Iterate  until  enough  estimated  means  from  different 
communication  systems  have  been  collected  to  build  a  95% 
Confidence  Interval  for  the  grand  mean  whose  bounds  are 
within  ten  percent  of  the  estimated  grand  mean.  Ensure 
that  a  minimum  of  30  Communication  Systems  are  used  for  the 
normality  assumption. 

**To  determine  a  "good  estimate"  for  a  single  Communication 
System:  make  all  calls  and  determine  the  percent 

successful;  repeat  until  enough  data  points  have  been 
collected  to  build  a  95%  Confidence  Interval  whose  bounds 
are  within  ten  percent  of  the  estimated  mean  percent  of 
successful  calls  for  that  Communications  System;  ensuring 
that  at  least  30  samples  are  collected  for  the  normality 
assumption . 


Additionally,  all  of  the  data  points  used  to  build  the 
above  estimates  were  collected  for  comparisons  of  high  and  low 
percentages  of  calls  successful.  This  provided  some  insight 
of  the  variability  of  the  protocol's  success  rate  on  various 
communication  systems. 

C.  GRAPHICAL  CAUSE  IDENTIFICATION 

To  completely  validate  the  protocol,  all  causes  of  any 
possible  failure  must  be  isolated.  The  simplest  way  to 
isolate  the  cause  of  detected  failures  is  by  using  the 
graphical  display  developed  for  TACFONE-NATO.  TACFONE-NATO' s 
graphical  display  provides  a  usable  problem  diagnosis  tool 
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which  allows  users  to  employ  their  intuition  to  identify 
failure  causes. 

A  method  for  generating  failed  call  displays  was  developed 
to  show  a  graphical  representation  of  failed  calls  on  screen. 
The  display,  which  continually  shows  the  calls  being  routed, 
freezes  when  an  attempted  call  fails.  The  originator,  path, 
and  intended  destination  light  up  in  unique  colors  so  they  can 
easily  be  identified.  By  analyzing  the  characteristics  of  the 
formations  involved,  it  may  be  possible  to  intuitively  deduce 
what  the  problem  is.  This  tool  proved  to  be  of  tremendous 
value  for  both  debugging  TACFONE-NATO  and  in  helping  to 
identify  problem  areas  in  the  STANAG  4214  protocol. 

D.  ISOLATING  CAUSES  FOR  FAILURES 

When  a  large  number  of  failures  exist,  it  is  impractical 
to  attempt  to  intuitively  determine  all  the  causes  of  failure 
using  the  graphical  display.  Even  when  only  a  small  number  of 
failures  occur,  intuition  may  fail  to  yield  a  cause  for 
failures.  To  assist  in  isolating  causes  for  failures  in  these 
cases,  a  mathematical  program  was  developed  to  single  out  the 
most  likely  set{s)  of  circumstances  which  lead  to  failures. 
The  development  of  this  program  will  now  be  discussed. 

1.  Possible  Outcomes  and  Assignable  Causes  for  Errors 
Each  call  can  experience  one  of  three  outcomes: 

1.  Be  complete  as  specified. 
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2.  Arrive  at  a  formation  which  has  already  handled  the 
call  (loop) . 

3.  Arrive  at  a  formation  which  has  no  way  of  reaching  the 
destination  (dead-end) . 

Each  simulated  call  n  involved  had  an  originating  formation 
fn  o,  and  a  destination  formation  Each  call  could  have 

many  feasible  paths  based  on  the  routing  tables.  Each  of 
these  feasible  paths  will  be  referred  to  as  an  attempt  for 
call  n.  To  validate  the  protocol  and  routing  table  entries, 
all  feasible  paths  must  be  examined.  Therefore,  each  call  is 
repeated  until  all  feasible  paths  have  been  examined.  Each 
attempt  records  its  journey  through  the  network,  building 
=  (f„,o/  fm.i'  /  where  is  the  formation  relaying 

attempt  m.  If  the  attempt  is  completed,  f „ ^ 

Now  record: 


1  if  attempt  is  successful; 

JC  -  2  if  attempt  loops; 

3  if  attempt  dead-ends. 

The  path  and  the  value  of  X  indicate  where  the  trouble - 
causing  switches  are  (i.e.,  routing  tables  at  these  switches 
may  be  causing  looping  or  dead-ends) .  Table  1  shows  some 
prime  suspects  for  different  completion  outcomes. 
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TABLE  1  LIKELY  CAUSES  FOR  FAILED  CALLS 


A™ 

Prime  Suspects  | 

1 

none  | 

2 

loop  includes  (f^,  .  .  . ,  ,  at  least  one 

outgoing  switc)i  should  omit  at  least  one  entry 

3 

fi.2  switch  overstates  formations  reachable 
fi.i  switch  overstates  formations  reachable 
fi  has  at  least  one  switch  which  has  an  omission 

2  or  3 

numbered  incorrectly 

The  prime  suspects  for  each  type  of  failure  can  now  be 
examined  to  attempt  to  determine  which  formation 
characteristics,  as  defined  in  the  next  section,  the  STANAG 
4214  protocol  has  trouble  in  handling. 

2.  ANALYZING  ERROR  DATA 

The  objective  of  this  part  of  the  analysis  is  to 
determine  the  causes  of  incomplete  calls  (attempts) . 
Incomplete  calls  arise  because  of  one  or  mo.  mistalces  in  the 
formation  of  the  routing  tables  in  the  switches,  or  in 
ambiguous  or  incorrect  formation  area  code  assignments.  Each 
formation  has  key  characteristics  which  determine  the  method 
used  to  assign  its  area  code  (number  the  formation)  and  the 
manner  in  which  it  forms  its  routing  tables. 

The  key  characteristics  of  any  formation  are: 

1.  ROLE:  Host (H) ,  Primary(P),  or  Secondary (S) ; 

2.  NATV:  true(T)  if  native  to  (same  nationality  as) 
parent,  false (F)  if  not; 
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3.  DUP:  true (T)  if  duplicate-capable,  false  (F)  if  not; 

4.  HRT:  single-routing (S)  if  Host  is  single-routing, 
multiple-routing (M)  if  Host  is  multiple-routing; 

5.  PRT  :  single-routing (S)  if  Parent  is  single-routing, 
multiple-routing (M)  if  Parent  is  multiple-  routing. 

Each  failed  call  is  caused  by  some  shortcoming  of  the 
numbering  rules  or  routing  tables  which  arise  from  some 
combination  of  these  characteristics.  For  example,  it  is 
possible,  albeit  improbable,  that  something  is  wrong  with  the 
rule  for  numbering  any  Secondary  formation.  It  is  also 
possible  that  secondary  formations  which  have  nationalities 
which  are  different  from  their  parent,  and  whose  parent  is 
multiple-routing,  are  not  all  numbered  correctly.  The 
objective  of  the  analysis  is  to  distinguish  the  precise 
combination  of  characteristics  under  which  calls  are  not 
reliably  routed  to  a  formation. 

3.  ALGORITHMIC  CAUSE  IDENTIFICATION 

It  is  reasonable  to  assume  that  the  "most  common"  kev 
characteristics  for  likely  suspect  formations  of  failed 
attempts  are  the  most  probable  to  be  those  which  the  STANAG 
4214  protocol  has  difficulty  handling.  This  makes  it 
desirable  to  determine  which  are  the  "most  common" 
characteristics  for  likely  suspects  of  failed  attempts. 
Visual  inspection  of  output  files  would  be  one  way  to  do  this, 
but  for  a  large  number  of  failed  attempts,  this  would  be  very 
tedious  and  time  consuming.  Therefore,  a  mathematical 
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program  was  developed  to  aid  in  finding  the  "most  common"  key 
characteristics  of  a  set  of  likely  suspects. 

For  each  failed  attempt  m,  collect  the  likely  suspects 
for  attempt  m  in  accordance  with  Table  1 .  Now  let 

1  if  a  prime  suspect  formation  for 
attempt  m  has  properties  ROLE, 
NATV,DUP,  HRT,  and  PRT 

®  ROLE. HATV,DUP, HRT, PRT 

0  if  the  combination  ROLE,  NATV 
DUP,HRT,  and  PRT  does  not  describe 
a  prime  suspect  for  attempt  m 

Let  a^jioLE . *  t>e  a  similar  indicator  variable  for  the 

ROLE  of  each  prime  suspect  for  attempt  m,  with  s'"  ^atv . / 

^  ROLE, .  ,DUP, . , . '  ^  ROLE,  NATV, PRT  *  etc . ,  Similarly  defined.  For 

example,  if  the  only  likely  suspect  for  failed  attempt  one  was 
a  duplicate-capable.  Secondary  formation  from  the  same  country 
as  its  Primary,  with  both  its  Host  and  Primary  formations 
multiple-routing,  then  the  following  a^'s  would  be  assigned 


the 

value  of  one;  s^s.t.t.m.m' 

a^ 

S,T,T,M,  . 

3^ 

/  S.T.T,  .  ,Mf 

3^ 

®  S.T,  .  ,M.M/ 

a's,. 

,T.M,M/ 

.,T,T.M,M/ 

3^  3^ 

®  S,T,T, , , , '  ®  S,T, . 

,M,  .  / 

a's,T,., 

3^ 

.  ,M'  ®  S,  .  ,T.M.  .  ' 

^  S,  .  .T,  .  ,M/ 

a's,. 

^  .  ,T,T,M,  .  f 

<=*  .,T,T,  ^  .,T,  . 

a\..,T, 

3^ 

®  S,T, 

®  S,  . ,T,  . ,  .  ' 

a^s,. 

. .  f 

3  S . M» 

3^  3^ 

®  . ,T,T. . , , ^  ^  . ,T, . 

a\.T,.. 

3^ 

.  ,M#  ®  . ,T,M,  .  ' 

3^ 

®  . .T,  . ,M/ 

a^  _ , 

. , 

a\,T . »  a".. 

.  .T,  . . 

a\, 

..  ..M,  .  r 

.,M-  The 

a^'s  representing  all  other  characteristic  combinations  would 
be  zero. 

Now  let  Zrole  „;^tv_i,up,hrt,prt  ®  similarly  indexed  decision 
variable  with  values  as  follows: 
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1  if  problems  arise  in 
implementing  STANAG  4214  for 
formations  with  properties 
ROLE,  NATV,  DUP,  HRT,  and  PRT; 

■2role,natv,dup,hrt,prt  ~ 

0  if  formations  with 
properties  ROLE,  NATV,  DUP, 
HRT,  and  PRT  are  handled 
correctly. 

xhese  variables  will  be  referred  to  as  cause  conclusion 
indicators.  If  one  conclusion  is  a  refinement  of  another 
(e.g.,  H,.,.,S,S  is  a  refinement  of  H,.,.,.,.),  the  more 

general  conclusion  indicator  is  referred  to  as  a  composite 
conclusion,  while  the  refinement  is  a  constituent  conclusion 
of  the  more  general  one.  These  variables  will  be  used  in  a 
simple  set-covering-like  optimization  which  will  have  as  its 
solution  the  likely  set  of  causes  (the  ones  which  occurred 
most  frequently)  for  the  given  set  of  failed  attempts.  Since 
it  is  reasonable  that  the  two  different  types  of  failures 
(loops  and  dead-ends)  would  be  caused  by  different  problems, 
the  sets  of  likely  suspects  will  be  grouped  by  the  type  of 
failure  they  were  a  suspect  for.  The  optimization  problem 
will  be  solved  for  each  of  these  groups  separately. 

Consider  the  following  mathematical  program  constraint 

set : 

^  ^  ^ ROLE,  NATV,  DUP,  HRT,  PRT  ^ROLB,  NATV,  DUP,  HRT,  PRT  (D 

for  each  failed  attempt  m,  where  S2  is  the  set  of  all  possible 
combinations  ROLE,  NATV,  DUP,  HRT,  PRT  with  ROLE  €  {H,  P,  5}, 
NATV  e  {T,  F},  DUP  6  { T,  F}  ,  HRT  €  {S,  M)  ,  and  PRT  G  {S,  M}  . 
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The  u,„  corresponds  to  not  being  able  to  assign  a  cause  to 
failure  w.  By  convention,  this  is  called  a  zero-factor 
conclusion.  This  set  of  constraints  will  produce  a 
combination  of  z's  and  u's  which  cover  all  of  the  failed 
attempts.  That  is,  for  each  failed  attempt  m,  either  u,„  is 
selected  or  at  least  one  of  failed  attempt  m's  likely  suspects 
has  the  characteristics  defined  by  at  least  one  of  the  z's 
selected.  Furthermore,  it  is  preferred  to  have  information 

which  is  as  precise  as  possible;  accepting  Zg .  as  one  is 

less  desirable  than  accepting  Zg^.T, which,  in  turn,  is 
less  desirable  than  accepting  Zstt.s.s-  The  objective  is  to 
produce  a  set  of  decision  variables  which  give  as  much 
information  as  possible.  On  the  other  hand,  if  Zh.t,t,s,s' 
^p,T,T,s,s/  2s_t,t,s,s  one,  what  really  exists  is  a 

situation  where  they  should  all  be  zero,  and  ,t,t.s,s  should  be 
one.  A  set  of  costs  will  now  be  constructed,  along  with  some 
more  constraints  so  that  the  program  produces  a  set  of 
indicated  causes  which  are  both  parsimonious  and  precise. 

Let  the  number  of  constituent  conclusions  for  each 
conclusion  variable  be  counted  and  denoted  by  nROLE.NATv.cup.HRT.pRT- 
By  definition,  let  nROLE.NATv.oup.HRx.pRT  =  1  for  all  five-factor 
indicators .  Then 

,NATV,DUP,HRT,  PRT  =  ^H.NATV,  DUP.HRT,  PRT 

■^P,NATV,DUP,HRT.PRT 
^S,NATV,DUP,HRT,  PRT 

=  3 

because  the  first  factor  has  three  states.  Similarly, 
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‘ROLE,  DUP,HRT,PRT 


2 


n 


because  the  second  factor  has  only  two  states.  That  is,  a 
four- factor  n  equals  the  number  of  options  for  the  missing 
factor.  Continuing  in  this  manner,  one  can  show 


^ROLE.NATV . 

■^ROLE.NATV.T,  . ,  . 

+ 

^ROLE.NATV.F,  . ,  . 

^ROLE.NATV,  .  ,S,  . 

+ 

^ROLE.NATV,  .  ,M,  . 

■^ROLE.NATV . S 

+ 

^ROLE.NATV,  .,M 

=  8, 


and  so  forth. 

The  basic  cost  structure  is  now  constructed  so  that 
the  cost  of  concluding  a  four-factor  conclusion  variable  is 
true  is  slightly  larger  than  the  cost  of  proclaiming  that  all 
of  the  constituent  conclusions  are  true.  This  will  promote 
specificity.  Continuing  in  this  spirit,  conclusions  with  less 
factors  will  be  made  just  slightly  more  costly  than  all  of  the 
constituent  conclusions.  To  accomplish  this  let 

^ROLE,NATV,DUP,HRT,PRT  ~  ^ROLB , NATV , DUP ,  HRT ,  PRT  0-01 

be  the  basic  cost  of  concluding  Zrole,natv,dup,hrt,prt  equals  one. 

While  this  basic  cost  structure  will  result  in 
determining  the  most  specific  characteristics  for  the  likely 
suspects,  it  does  not  guarantee  that  the  most  common 
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characteristics  will  be  identified.  Consider  a  group  of 
likely  suspects  for  a  failed  attempt  with  all  but  one  of  the 
suspects  having  identical  five-factor  characteristics.  Both 
of  the  feasible  five -factor  conclusion  variables  have  the  same 
positive  cost  and  both  would  cover  the  failed  attempt.  Since 
the  goal  is  to  minimize  cost,  the  mathematical  program  will 
only  allow  one  of  the  conclusion  variables  to  take  on  the 
value  one.  Since  each  of  the  conclusion  variables  have  the 
same  cost  under  the  basic  cost  structure,  the  mathematical 
program  would  be  just  as  happy  to  chose  the  lone  suspect's 
five-factor  conclusion  as  the  five-factor  conclusion  of  all 
the  other  suspects.  In  order  to  give  more  weight  to 
conclusions  which  appear  more  frequently,  the  final  cost  for 
a  particular  conclusion  is  made  as  follows: 

^ROLE,NATV,DUP,HRT,PRT  “  •^OLE,  NATV,  DUP,  HRT,  PRt/ ^ROLE,  NATV,  DUP,  HRT,  PRT 

Where  tROLE,NATv,DUP,HRT,PRT  IS  the  maximum  of  one  and  the  total 
number  of  all  likely  suspects  with  the  given  n-fold  factor 
conclusion. 

Recall  that  if  all  of  the  five-factor  constituent 
conclusions  are  chosen  for  some  four- factor  conclusion,  it  is 
desired  to  force  the  choice  of  the  four-factor  conclusion 
instead.  To  ensure  that  conclusions  with  less  factors  are 
chosen  when  appropriate,  the  following  constraint  set  must  be 
added  to  the  mathematical  program: 
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,T,T,S,S^.  ,T,T,S,S  * 

^H,T,T.S,S 

^S,T,T,S,S 

^P,T,T,S,S 

1) 

(2) 

,T,T,S,M^.  ,T,T,S,M  * 

+  ^S,T,T,S.M 

^P.T,T,S,M 

1) 

(3) 

^H,T,F,  .  ,  .  ^H.T.F,  . ,  .  *  ^H.T,F,S,  .^H.T.F.S,  .  ^H,T,  F,M,  .  T,  F,  M,  . 

~  ^^H,T,F,.,.  ”  (4) 


^H,T,F,  . 

.^H.T,F, 

2 

^H,T,F,  . 

,sZh,T,F,  .,s  + 

^H.T.F, 

.  ,mZh,T,F,  .  ,M 

• 

- 

T,F,.,.  "  1) 

(5) 

.  ,F,  . 

.,F, 

2 

^H,T,F,  . 

,  .Zh,T,F,  + 

^H,F,F, 

. ,  .  Zh,f,F,  . ,  . 

- 

-  ,P.  .  ,  .  '  D 

(6) 

.  ,F,  . 

.  .  ,F.  .  , 

2 

.  ,F,S 

,  .Zh,  .,F,S,  . 

.  ,F, 

M,  .Zh,  .  ,f,m,  . 

- 

.  ,F,  . ,  .  “  1  ) 

(7) 

.  ,F,  . 

.  .  ,F,  . , 

2 

^H,  .  ,F,  . 

,sZh,.,f,.,s  + 

.  .F, 

.  ,mZh,  .  ,f,  .  ,m 

• 

- 

.,F,  ...  ~  1) 

(8) 

. 

. 

2 

^H,T,  . ,  . 

.Zh,t .  + 

^H.F,  . , 

.,.z„,p . 

-  (n„. 

.  -  1) 

(9) 

. 

.  Zh . 

2 

.  ,T,  . 

,  .Zh,  .,T, + 

.  ,F, 

. , .  Zh, 

-  (n„, 

.  -  1) 

(10) 

. 

.Zh . 

2 

.  ,S 

,  Zh . s,.  + 

^H . M,  .  Zh . M,  . 

- 

.  -  1) 

(11) 

_ 

.z„ . 

2 

riH . 

,sZh . s  + 

^H . 

.  ,mZh,  . , . , .  ,m 

- 

. -  1) 

(12) 

A  check  of  these  constraints  shows  that  if  the  program  selects 
an  entire  set  of  constituent  conclusions,  the  composite 
conclusion  is  chosen  as  well.  However,  since  there  would  then 
be  a  redundancy,  the  cost  structure  will  ensure  that  the 
constituent  conclusions  will  be  dropped  when  possible.  Thus, 
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by  combining  the  set -covering  constraints  (Equation  1)  with 
forced  composite  constraints  (Equations  2-12) ,  the  feasible 
region  of  a  mathematical  program  is  defined.  The  objective 
function,  given  as 


min 


ROLE,  NATV.DUP.HRT.PRT^ ROLE.  WiTV.DUP.HnT.PRT  *  X/ 

in=l 


U. 


where  n  is  defined  as  before  and  t  is  the  total  number  of 
failed  attempts,  completes  the  specification  of  the 
mathematical  program.  This  optimization  is  solved  using  some 
of  the  methods  found  in  Balas  (1980)  and  the  General  Algebraic 
Modeling  System  (GAMS)  software  pac)cage. 

E.  ANALYSIS  OF  MULTIPLE  COMMUNICATIONS  SYSTEMS 

As  previously  mentioned,  it  is  possible  to  sample  random 
variates  to  perform  single-system  chec)cs  on  numerous  different 
force  structures.  The  data  from  these  single-system  checlcs 
can  then  be  consolidated  to  develop  a  single  set  of  failed 
attempts  from  various  different  communications  systems.  Using 
this  technique,  it  is  possible  to  enlarge  the  set  of  different 
equipment  combinations  checlced  by  the  program. 


F.  SUMMARY 

The  measure  of  effectiveness  for  the  STANAG  4214  protocol 
was  defined  as  the  mean  percentage  of  successful  calls  in  a 
random  communication  system  when  each  formation  calls  every 
other  formation  once.  Additionally,  two  methods  for  isolating 
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failure  causes  were 
and  a  mathematical 


developed:  Graphical  Cause  Identification 
program . 
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VI .  RESULTS 


This  chapter  will  discuss  the  results  obtained  from  using 
TACFONE-NATO  to  assist  in  performing  the  analyses  set  forth  in 
Chapter  V. 

A.  RESULTS  OF  ESTIMATED  SUCCESS  RATES 

Table  2  consolidates  the  results  of  the  estimated 
effectiveness  of  the  protocol  for  a  random  Communication 
System  in  terms  of  percentage  of  successful  calls  when  each 
formation  calls  every  other  formation  once  and  the  path  is 
randomly  chosen  when  more  than  one  possible  path  exists.  The 
results  for  the  runs  without  lateral  connections  were  derived 
from  30  randomly  generated  Communication  Systems  making  a 
total  of  2,850,300  simulated  calls  for  each  set  of  rules 
evaluated. 

The  lateral  connection  rules  were  tested  on  six  randomly 
generated  Communication  Systems  with  each  formation  being 
connected  to  every  other  formation  (i.e.,  every  possible 
lateral  connection  was  made) .  The  purpose  of  connecting  all 
formations  was  to  put  the  maximum  amount  of  stress  on  the 
lateral  connection  rules,  regardless  of  how  unlikely  it  would 
be  for  this  situation  to  occur.  The  test  for  the  lateral 
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TABLE  2  PERCENTAGE  OF  SUCCESSFUL  CALLS. 


Rules  Invoked 

Estimated 
Expected 
Success  Rate 
for  a  Random 
CommSystem 

Low 

Estimated 
Rate  for  a 
CommSystem 

High 

Estimated 
Rate  for  a 
CommSystem 

Basic  STANAG 
(No  Anti -Looping) 

90.53 

66.27 

100 . 00 

Basic  STANAG 

With  Anti -Looping 

99.54 

94.04 

100 . 00 

Basic  STANAG 

With  Anti -Looping  & 
Numbering  Change 

100.00 

100 . 00 

100 . 00 

Basic  STANAG 

With  Anti -Looping, 
Numbering  Change  & 
Lateral  Connections 

100 . 00 

100 . 00 

100 . 00 

connection  rules  checked  each  possible  path  (based  on  the 
routing  tables)  to  verify  that  no  possible  loops  existed. 

Table  2  reveals  the  tremendous  improvement  obtained  by 
invoking  the  anti-looping  rules  set  forth  earlier.  The  table 
also  shows  that  the  numbering  modification,  in  conjunction 
with  the  anti-looping  rules,  appears  to  eliminate  all  failed 
calls  using  the  STANAG  4214  protocol.  The  100  percent  success 
rate  for  systems  with  all  possible  lateral  connections  also 
demonstrates  the  effectiveness  of  the  lateral  connection  rules 
which  were  imposed  on  the  model . 

It  should  be  noted  that  Table  2  gives  the  expected  success 
rate  for  a  random  communication  system.  The  actual  expected 
success  rate  for  a  given  system  may  vary  significantly  from 
these  numbers  for  the  basic  model  and  for  invoking  only  the 
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anti-looping  rules.  It  would  not  vary  for  the  implementation 
of  all  rules  since  in  this  case  all  systems  have  a  100  percent 
expected  success  rate.  For  instance,  a  Communication  System 
with  three  or  fewer  Hosts  will  have  no  possible  loops. 
Therefore,  if  no  dead-ends  were  possible,  it  would  have  a  100 
percent  success  rate  even  without  invoking  the  anti -looping 
rules.  On  the  other  hand,  a  large  system  with  six  fully 
connected  Hosts  would  probably  have  something  near  the 
observed  low  66  percent  success  rate. 

Since  any  system  randomly  generated  was  regarded  equally 
as  likely  to  occur.  Table  2  weights  each  Communication  System 
equally  in  determining  the  expected  success  rate  for  a  system. 
This  means  that  a  large  system  making  thousands  of  calls 
resulting  in  perhaps  say,  a  70  percent  success  rate,  is 
weighted  the  same  as  a  small  system  making  only  a  few  dozen 
calls  with  a  100  percent  success  rate.  In  an  attempt  to 
determine  the  protocol's  effectiveness  for  a  random  single 
call,  the  total  number  of  calls  made  and  the  total  number  of 
successful  calls  were  also  collected  for  each  set  of  rules 
invoked.  These  results  can  be  seen  in  Table  3. 

The  80  percent  success  rate  for  the  basic  model  compared 
to  the  99.89  percent  success  rate  for  the  anti-looping  rules 
only  in  Table  3  shows  even  more  clearly  that  looping  is  a 
problem  which  must  be  dealt  with.  The  99.89  percent  success 
rate  for  implementing  anti-looping  rules  only,  also  shows  that 
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TABLE  3  EXPECTED  SUCCESS  RATE  FOR  A  RANDOM  CALL 


Rules  Invoked 

Total 
Number  of 
Calls 

Number  of 
Successful 
Calls 

Estimated  | 

Success  Rate  | 
for  a  Random  | 
Call 

Basic  STANAG 
(No  Anti -Looping) 

2,850,300 

2,287,056 

80,24 

Basic  STANAG 

With  Anti -Looping 

2,850,300 

2,847,303 

99 ,89 

Basic  STANAG 

With  Anti-Looping  & 
Numbering  Change 

2,850,300 

2,850,300 

100.00 

Basic  STANAG 

With  Anti-Looping, 
Numbering  Change  & 
Lateral  Connections 

98,622 

98,622 

100 . 00 

the  only  rule  discrepancy  discovered  results  from  a  situation 
which  apparently  occurs  rather  infrequently.  However,  to 
ensure  a  100  percent  success  rate  for  any  possible 
communication  system,  this  problem  must  too  be  remedied.  It 
is  also  apparent  that  the  anti-looping  heuristic  and  proposed 
rule  change  eliminated  all  failed  calls  and  that  the  lateral 
connection  rules  worked  flawlessly  even  under  the  most  arduous 
circumstances , 

B.  RESULTS  OF  FAULT  ISOLATION  PROGRAM 

The  mathematical  program  discussed  in  Chapter  V  was  used 
for  the  basic  model  (no  modifications  invoked) ,  the  basic 
model  with  anti-looping  (but  no  other  rule  modifications)  ,  and 
the  basic  model  with  anti-looping  and  a  proposed  modification 
to  the  protocol.  These  results  will  now  be  discussed. 


69 


1.  The  Basic  Model 


By  far,  the  greatest  problem  encountered  in  the  basic 
model  was  with  looped  calls.  The  list  of  conclusion  variables 

from  the  mathematical  program  included  only  Zhost.t .  (note 

that  Hosts  were  assumed  to  be  their  own  parent,  hence  all 
Hosts  were  assigned  a  "T"  for  NATV) .  This  showed  that  Host 
formations  were  the  most  common  (and  likely  the  only)  factor 
in  looped  calls.  Hence,  anti-looping  rules  for  inter-host 
connections  should  be  sufficient  to  eliminate  looping. 

There  was  also  a  problem  with  dead-end  calls.  Using 
both  the  mathematical  program  and  the  graphical  display,  it 
was  possible  to  identify  a  protocol  problem  with  the  numbering 
of  duplicate-capable  Secondary  formations  which  have  a 
multiple-routing  Host  and  a  single -routing  Parent  (Primary) . 
The  problem  only  occurs  vl.en  unere  are  other  formations  from 
the  same  country  in  the  network  who  do  not  have  the  same 
parent,  see  Figure  18.  When  this  situation  occurs,  at  least 
two  of  the  like-country  formations  are  numbered  the  same  using 
STANAG  protocol.  This  results  in  ambiguity  for  the  single¬ 
routing  Primary  when  attempting  to  route  a  call  to  one  of 
these  like-numbered  formations,  as  one  of  the  two  possible 
switch  choices  does  not  route  to  the  desired  formation,  see 
Figure  18.  Since  the  Primary  is  only  single-routing  capable, 
there  is  at  least  a  50  percent  chance  (if  each  possible  switch 
is  chosen  with  equal  likelihood)  that  the  call  will  fail.  The 
STANAG  rule  for  numbering  such  Secondaries  states: 
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Multiple  Houter 
Host  Germany 
AC:  804 


Single  Router 
I  Primary  UK 
I  AC:  804 


Secondary 
liuplicate  Capatbl 
France  AC:  804 


le 


Secondary  i 
£juplicate  Capable 
France  AC:  81  ^ 


jMultlple  Routei 
rimary  Germarjy 
AC:  804 


Secon 
1—1  Denn 
AC:1 
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Implicate 
France  !■ 


Secon 
Germ 
AC:  I 


Figure  18  Numbering  rule  problem. 
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If  the  major  host  formation  and/or  the  formation  under 
direct  command  are  only  capable  of  "single"  routing  chen 
its  secondary  formations  shall  be  assigned  unique  prefixes 
....  (STANAG  4214,  1985,  p.B-6) 

This  rule  was  interpreted  to  mean  that  all  Secondary 
formations  of  a  single-routing  Primary  and  multiple -routing 
Host  must  be  numbered  uniquely  amongst  themselves.  The 
recommended  solution  to  this  problem  is  to  have  the  STANAG 
clearly  state  that  all  such  formations  must  be  numbered 
uniquely  from  all  other  formations  in  the  entire  network. 

2.  The  Model  With  Anti-Looping  Rules  Only 

After  imposing  the  anti-looping  rules  (and  lateral 
connection  rules)  stated  previously,  no  failures  were 
encountered  due  to  looping  in  communication  systems  even  with 
lateral  connections.  However,  the  problems  with  dead-end 
calls  persisted. 

3.  The  Model  With  Recommended  Change  to  STANAG  4214 

With  the  implementation  of  the  recommended  change  for 
the  numbering  problem  mentioned  earlier,  along  with  the  use 
anti-looping  rules  and  lateral  connection  rules,  no  failures 
of  any  kind  were  encountered  for  numerous  randomly  generated 
Communication  Systems. 

C.  SUMMARY 

The  results  of  the  success  rate  analysis  and  the  fault 
isolation  analysis  reveal  that  looping  is  the  single  most 


72 


likely  cause  for  failures  if  it  is  not  dealt  with  properly. 
Fortunately,  the  results  also  show  that  the  proposed  anti- 
looping  rules  work  flawlessly  in  preventing  looping.  Finally, 
the  results  also  revealed  an  error  in  the  numbering  of 
duplicate-capable  Secondaries  with  a  multiple-routing  Kcct  and 
a  single -routing  Primary.  Further  analysis  showed  that  the 
recommended  rule  changes  alleviated  the  numbering  problem. 
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VII.  CONCLUSIONS  AND  RECOMMENDATIONS 


The  primary  goals  of  this  study  were  to  test  the  protocol 
of  STANAG  4214,  develop  anti- looping  rules  for  inter-host 
connections,  and  develop  rules  to  allow  for  lateral 
connections  within  a  Communication  System  without  allowing 
looping.  To  this  end  the  object-oriented,  graphical 
simulation  model  TACFONE-NATO  was  developed.  Through  the  use 
of  this  model,  in  conjunction  with  a  mathematical  program 
developed  for  additional  analysis,  the  following  were 
accomplished; 

1.  The  need  for  reliable  anti-looping  rules  was  verified. 

2.  A  numbering  discrepancy  in  the  STANAG  4214  protocol  was 
discovered  and  isolated.  The  discrepancy  deals  with  the 
numbering  of  duplicate-capable  Secondaries  with  a  multiple¬ 
routing  H?st  and  a  single-routing  Primary. 

3.  Recommended  anti-looping  heuristic,  numbering  change 
and  lateral  connection  rules  were  tested  and  verified. 

In  addition,  TACFONE-NATO  will  allow  JIEO  and  other  users 


to : 

1.  Automatically  number  (using  STANAG  4214  protocol), 
build  routing  tables  for  a  user-defined  Communication 
System  and  output  this  information  to  a  user-selected  file. 
The  program  automatically  invokes  the  lateral  connection 
rules  via  the  building  of  the  routing  tables  and  can  also 
be  selected  to  use  the  anti-looping  heuristic  and  proposed 
numbering  rule  change. 

2.  Determine  the  effectiveness  of  a  user  defined  system 
which  has  already  been  numbered.  In  this  case  routing 
tables  will  be  built  by  the  model  (the  use  of  the  anti¬ 
looping  heuristic  is  determined  by  the  user) . 
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3.  View  a  randomly  generated  system  or  user-defined  system 
graphically. 

The  graphical  interface  developed  for  TACFONE-NATO  makes  the 
program  simple  to  run  and  allows  for  easy  selection  of  user 
options . 

This  analysis  of  STANAG  4214,  which  required  generating 
over  ten  million  simulated  phone  calls,  reveals  that  looping 
is  a  critical  problem  which  must  be  avoided  and  that  there  is 
a  flaw  in  the  current  protocol.  However,  this  analysis  also 
verifies  the  effectiveness  of  the  protocol  when  implemented 
with  TACFONE-NATO' s  anti-looping  rules  and  recommended 
numbering  modification.  It  is  recommended  that  the  anti¬ 
looping  heuristic  developed  for  and  used  in  TACFONE-NATO  be 
utilized  as  the  means  to  prevent  looping.  It  is  also 
recommended  that  STANAG  4214  be  modified  to  incorporate  the 
suggested  rule  change.  Finally,  this  analysis  also  shows  that 
lateral  connections  may  be  allowed  to  exist  under  the  rules 
set  forth  in  Chapter  V  without  degrading  the  protocol's 
effectiveness . 
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APPEKDIX  A 


SUBSIDIARY  AREA  CODES  ALLOCATED  TO  NATIONS 


Nation  Number  of  Master  ACs  Subsidiary  ACs 

Major  (Host) 

Formations 


Belgium 

2 

800 

200, 

300, 

400 

700 

Canada 

1 

801 

201, 

301, 

401 

Denmark 

1 

802 

202, 

302, 

402 

France 

4 

803 

818, 

203, 

218 

703 

718, 

303, 

318 

603 

618, 

402, 

418 

503 

Germany 

4 

804 

819, 

204, 

219 

704 

719, 

304, 

319 

604 

619, 

404, 

419 

504 

Greece 

1? 

805 

205, 

305, 

405 

Iceland 

1? 

806 

206, 

306, 

406 

Italy 

3 

807 

207, 

307, 

407 

707 

607 

Luxembourg 

1? 

808 

208, 

308, 

408 

Netherlands 

1 

809 

209, 

309, 

409 

Norway 

1 

810 

210, 

310, 

410 

Portugal 

1? 

811 

211, 

311, 

411 

Turkey 

1? 

812 

212, 

312, 

412 

UK 

2 

813 

213, 

313, 

413 

USA 

4 

814 

816, 

214, 

216 

714 

716, 

314, 

316 

614 

616, 

414, 

416 

514 

NICS 

1 

815 

- 

COMLANDJUT 

1 

715 

315 

Spain 

1? 

817 

217, 

317, 

417 
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APPENDIX  B 


USER  MANUAL  FOR  TACPONE-NATO 
I .  INTRODUCTION 

TACFONE-NATO  is  designed  to  simulate  the  STANAG  4214 
numbering  and  routing  protocol.  It  is  assumed  the  user  has  a 
working  knowledge  of  STANAG  4214  and  is  familiar  with  the 
terminology  used  in  this  document,  as  well  as  the  thesis  on 
this  subject.  TACFONE-NATO  simulates  a  communication  system's 
crucial  elements  in  order  to  allow  the  implementation  of  the 
STANAG  4214  protocols.  The  entire  model  was  designed  to 
represent  the  physical  equipment  and  the  actual  process  of 
sending  and  receiving  calls,  but  only  at  the  level  of  fidelity 
for  each  element  that  was  required  for  this  study.  Therefore, 
some  elements  that  are  modeled  may  not  exactly  reflect  the 
actual  equipment /process,  but  for  the  purposes  of  testing  the 
STANAG  or  a  different  numbering  system,  it  reflects  accurately 
the  portion  affecting  the  numbering  of  formations  and  routing 
of  calls.  The  model  is  completely  supported  with  graphics, 
which  allows  for  ease  of  use  and  simplifies  the  analysis  of 
results . 

The  information  in  this  users 's  manual  is  presented  in  the 
following  format: 

Chapter  I  Introduction,  Definitions,  and  Overview 

Chapter  II  Session  using  TACFONE-NATO 
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Chapter  III  Input  Files 

Chapter  IV  Output  Files. 

A.  BASIC  MODEL  OBJECTS 

What  follows  is  a  description  of  the  basic  building  blocks 
of  TACFONE-NATO.  As  discussed  previously,  these  are  the 
crucial  elements  of  a  communication  system  required  to 
evaluate  of  the  STANAG  4214  protocol. 

1 .  Communication  System 

The  communication  system  consists  of  a  set  of  networks 
that  are  connected  only  through  the  Host  formations.  These 
networks  are  connected  in  such  a  way  to  comprise  a  connected 
graph  of  all  networks  and  may  be  comprised  up  to  a  fully 
connected  graph. 

2 .  Networks 

A  network  is  a  hierarchically  constructed  tree  of 
formations  with  a  maximum  of  three  levels,  called  Host, 
Primary,  and  Secondary.  The  only  connections  allowed  between 
formations  in  a  network  are  the  ones  that  follow  this  tree 
structure.  Therefore,  under  current  STANAG  4214  protocol,  the 
Secondary  formations  only  have  one  connection,  which  is  with 
their  parent  (Primary)  formation.  The  Primary  formations  have 
one  connection  with  each  of  their  children  (Secondaries)  and 
one  connection  with  their  Host  formation.  Each  Host  formation 
has  one  connection  with  each  of  his  child  Primary  formations 
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and  connections  to  other  Host  formations,  depending  on  the 
topology  of  the  communication  system. 

3 .  Formations 

The  formations  represent  the  communication  systems  for 
different  sized  military  units.  Generally,  Host  level 
formations  represent  Corps-sized  units.  Primary  level 
formations  equate  to  division-sized  units  and  Secondary  level 
formations  represent  brigade-sized  units.  The  STANAG  4214 
protocol  does  not  address  units  of  any  smaller  size, 
therefore,  TACFONE-NATO  does  not  represent  any  other  unit 
types . 

4.  Switches,  Trunks  and  Gateways 

These  elements  are  modeled  to  reflect  definitions  as 
described  in  STANAG  4214. 

B.  NUMBERING  THE  COMMUNICATIONS  SYSTEM 

The  model  numbers  the  Communications  System  according  to 
the  rules  of  the  STANAG  4214  with  the  exception  of  options  to 
be  discussed  in  later  sections. 

C.  GENERATION  OF  COMMUNICATION  SYSTEMS 

TACFONE-NATO  will  either  read  in  a  user-defined  force 
structure,  or  randomly  generate  a  force  structure.  If  the 
force  is  user-defined,  TACFONE-NATO  can  automatically  number 
the  communication  system,  or  the  NIACs  can  be  defined  by  the 
user.  This  gives  the  user  the  flexibility  to  analyze  a 
proposed  numbering  scheme  that  does  not  follow  the  STANAG 
rules.  The  connections  between  networks  at  the  Host  level  are 
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either  randomly  generated  by  TACFONE-NATO  or  defined  by  the 
user.  When  the  communication  system  is  generated  randomly, 
the  number  of  networks,  formations,  and  connections  between 
networks  are  all  randomly  determined  from  preset  bounds.  The 
identity  of  the  formations,  including  nationality,  are  also 
randomly  determined  from  the  existing  units  that  are  available 
to  NATO.  Once  the  force  has  been  generated  and  connected,  the 
formations  are  numbered  using  the  method  previously  discussed. 

When  the  program  automatically  numbers  a  user-defined 
force  structure  it  is  possible  that  a  Host  nation  mat  not  have 
enough  subsidiary  area  codes  assigned  to  it .  If  this  occurs, 
the  program  will  halt  and  inform  the  user  which  nation 
requires  more  subsidiary  area  codes.  Adding  of  area  codes  can 
be  done  by  modifying  the  "AREACODE.DAT"  file,  see  chapter 
three,  INPUT  FILES,  for  further  information  on  how  to  modify 
this  file. 

D.  BUILDING  OF  ROUTING  TABLES 

Once  the  communication  system  is  generated  and  has  been 
numbered,  the  routing  tables  are  initialized  for  each  trunk  of 
each  formation.  Each  network  first  updates  its  routing  tables 
internally,  then  the  switches  connecting  the  networks 
initialize  their  routing  tables.  The  basic  model  allows  all 
paths  that  exist  from  one  network  to  another  to  be  reflected 
in  the  routing  tables.  The  STANAG  4214  does  not  d:  rectly 
address  what  paths  should  exist  from  one  network  to  another, 
only  that  it  is  done  in  a  way  "to  prevent  looping"  .  The  basic 
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model  operates  this  way  to  give  the  ability  to  measure  the 
effectiveness  of  anti -looping  rules  which  were  added  to  the 
model . 

E.  GENERATING  AND  ROUTING  CALLS 

Calls  are  generated  from  every  formation  to  every  other 
formation.  The  formation  routes  a  call  based  on  the  physical 
limitations  of  communications  equipment  of  its  nation,  as  well 
as  the  contents  of  its  switches'  routing  tables.  Between 
networks,  calls  are  only  routed  via  one  path  (single-routed)  . 
The  call  tracks  all  formations  that  it  is  routed  through  to 
reach  its  destination.  Calls  are  not  allowed  to  be  routed 
immediately  back  along  a  trunk  just  used  to  reflect  the  actual 
physical  limitations. 

F .  GRAPHICS 

The  TACFONE-NATO  model  utilizes  the  SIMGRAPHICS  (MODSIM 
93)  portion  of  MODSIM  to  display  all  input  and  output 
graphically.  The  model  is  controlled  through  the  use  of 
graphical  user  interfaces,  all  mouse-driven.  This  eases  the 
use  of  TACFONE-NATO  dramatically,  by  making  it  much  more  user- 
friendly.  The  Communication  System  is  displayed  on  the  screen 
graphically  using  a  separate  window  for  each  network.  Each 
formation  is  displayed  as  a  rectangle  with  its  nationality, 
unit  size  (corps,  division,  or  brigade) ,  unit  number,  and 
NIAC.  All  trunks  are  represented  as  lines  between  the 
formations.  The  Host  formations  are  also  displayed  in  a 
separate  window  with  their  inter-host  connections  also 
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displayed  as  lines.  When  calls  are  being  routed,  the 
originator  formation  and  the  destination  formation  are 
uniquely  colored  and  all  trunks  in  the  path  are  also  colored 
to  allow  the  user  to  visually  watch  the  calls  be  routed.  The 
display  is  frozen  when  a  failed  call  occurs,  which  aids  in  the 
trouble  shooting  of  any  protocol  problems. 
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II.  A  SESSION  USING  TACFONE-NATO 


Figure  1  below  shows  the  basic  flow  for  a  run  of  TACFONE- 
NATO.  The  specifics  of  each  of  these  steps  will  be  discussed 
in  more  detail  throughout  the  remainder  of  this  Chapter. 


Start 

_1_ 


StedinQ  Method 


Manual 


Auto 

Comm  System 
CapaOiiities 


Ente#  Seeds 


Read  In 


Enter  File  NAme(s) 


Select  Run  Type 


User  Determined  Number  Qf 
Comm  Systems  * 


Other  I  ^ 

^elect  Oesired  Output 


Enter  Number 


Output  Destred 


T 


ErrterRiie  Name<s) 


Select  Rule  Changi^r 
Oesired 


p  Select  Method  of 
I  Generafion 


Read  in 


Select  Numbering 
Method 


Auto 


Enter  file  Name 


Select  Connecting 
Method 


Read-in 


Enter  file  Neune 


Begin  Run 


Figure  1  System  flow  for  a  run  of  TACFONE-NATO. 


To  start  the  program  type  TACFONE  at  the  command  line  in 
the  directory  where  the  executable  file  and  all  input  files 
are  stored.  The  first  option  presented  is  how  to  set  the 
random  number  generator  seeds:  automatically  or  manually,  see 
Figure  2 . 
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To  pick  the  option 


Manually  Enter  Random  Number  Ceneratof  Seeds  | 

Click  here  when  choice  is  complete  J 

Figure  2 :  Random  Number 
"click  here  when  choice  is  Generator  Seed  Choice  Box. 

complete"  button  to  move  on. 

The  random  number  generator  is  used  when  randomly  generating 
a  communication  system  and  when  the  calls  are  being  routed. 
If  the  same  seeds  for  the  generators  are  used  for  two  separate 
runs,  the  exact  same  results  will  be  produced  (all  other 
options  consistent)  .  The  seeds  will  be  set  to  the  same  preset 
numbers  every  time  the  automatic  seeding  is  chosen.  It  is 
possible  to  view  different  randomly  generated  systems  by 
choosing  to  manually  enter  different  seeds. 

When  the  manual  method  for  setting  the  random  generator 
seeds  is  chosen,  the  screen  snown  in  Figure  3  will  be 
displayed.  There  are  five 
random  number  generators 
utilized  by  TACFONE-NATO, 
which  means  five  seeds  are 
required  to  be  set.  To  enter 
a  number  (seed) ,  place  the 
mouse  cursor  on  the  desired 
line  and  type  in  the  number. 

Ensure  there  are  no  spaces! 

To  switch  to  another  line. 


Seed  1 

♦ 

1 

Seed  2 

♦ 

1 

Seed  3 

♦ 

1 

Seed  4 

♦ 

1 

Seed  5 

♦ 

1 

Click 

here 

when  done  j 

Figure  3  Random  Number 
Generator  Seed  Entry  Box. 


desired,  click  the 
appropriate  button  with  the 
mouse  and  then  click  the 
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use  the  mouse  or  the  arrow  keys.  Once  all  numbers  have  been 
entered,  click  the  "click  here  when  done"  button  with  the 
mouse.  The  next  option  presented  is  whether  or  not  the 
duplicate -capable,  and  single/multiple-router  information  for 
each  country's  communications  equipment  will  be  read  in  {to 
reflect  actual  capabilities)  or  be  randomly  generated  by 
TACFONE-NATO  (to  allow  for  more  robust  testing  of  the  rules) . 
Two  choices  must  be  made  on 
this  screen,  one  for  each 
type  of  capability,  (see 
Figure  4  for  the  actual 
screen) .  Once  the  choices 
are  made,  click  the  "click 
when  done"  button  with  the 
mouse . 

If  either  of  the  options 
to  read  in  capabilities  from 
a  file  was  selected. 

Figure (s)  5  and/or  6  will  be 
displayed,  depending  on  the 
selections.  Enter  the  appropriate  file  name(s)  on  the  line  by 
clicking  on  the  line  and  typing  the  name  from  the  keyboard. 
Once  the  file  name  is  entered,  click  the  "click  here  when  file 
name  is  entered"  button  with  the  mouse. 


lijftirfTWtion 

Read  In  Duplicate  Capable  Information  From  a  file  | 

I  Information 

Read  In  Single/Multiple  Router  Information  From  a  file  | 


|^^Cll(ct^iengj»hen^on^making^hoice^^^^^^ 

Figure  4  Equipment 
Characteristics  Choice  Box. 


Figure  5  Duplicate  Capable 
Information  File  Name  Box. 
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The  next  screen  allows 
for  the  selection  of  what 


type  of  run  is  to  be 


conducted,  see  Figure  7  for 
an  example  of  this  choice. 

The  choices  are  defined 


as : 


1.  Calculate  percent 
successful  Calls. 

This  option  requires  a 
minimum  of  900  runs 
and  approximately  25 
hours  to  complete . 

The  run  randomly  generates  a  communication  system  and 
generates  calls  from  each  formation  to  every  other 
formation  using  only  one  path  to  reach  it's 
destination,  calculating  the  percentage  of  successful 
calls.  The  calls  are  then  regenerated  at  least  30 
times  until  the  95  percent  confidence  interval  for 
percentage  of  successful  calls  is  within  10  percent  of 
the  estimated  mean.  The  same  is  done  for  at  least  30 
different  communication  systems  to  estimate  the 
expected  success  rate  for  a  random  system.  Once 
complete,  the  statistical  data  is  printed  in  the 
output  file  designated  by  the  user. 

2.  User  determined  number  of  communication  systems  to  be 
user  defined  or  randomly  generated.  Calls  will  be 
made  from  every  formation  to  every  other  formation 
utilizing  only  one  path  to  route  the  call.  Dependent 
on  the  size  of  the  system  and  number  of  failed  calls 
the  amount  of  time  required  is  approximately  2-45 
minutes  for  each  communication  system. 

3.  Complete  fault  checking  of  a  user  defined  or  randomly 
generated  communication  system.  Calls  will  be 
generated  from  every  formation  to  every  other 
formation  utilizing  all  routes  possible  to  determine 
if  there  are  any  potential  failures  in  the 
communication  system  based  on  it's  numbering  and  the 
routing  table  configurations.  If  there  are  any 
failures  the  attributes  of  the  suspected  formations 
which  may  have  caused  the  failure  are  printed  in 


jtOUTING.DAT 

Click  here  when  file  name  is  entered  j 

_ 

Figure  6  Single  Router 

Information  File  Name  Box. 


C«lcul«te  Percent  Successful  Calls(Mintfnum  900  Runs) 

User  Determined  fi^mber  of  Comm  Systems 

Determine  Numbermg  end  Routing  Ttblei  oT i  Retd  m  System 


j  Click  here  when  type  of  run  hts  been  chosen  '  J 

Figure  7  Type  Of  Run  Choice 
Box. 
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various  files.  The  file  names  are  printed  on  the 
screen  at  the  end  of  the  run.  The  time  required  for 
each  communication  system  is  approximately  twice  as 
much  as  option  two. 

4.  Number  a  user  defined  communication  system.  This 

option  will  take  the  user  defined  communication  system 
and  determine  the  numbering  of  all  the  formations  and 
the  routing  table  configurations  for  each  switch.  The 
user  can  graphically  view  the  system  with  the  graphics 
option,  but  no  calls  will  be  simulated  with  this 
option.  This  option  will  require  less  than  two 
minutes . 


Option  1  allows  the  user  to  determine  the  expected 
operational  effectiveness  of  a  set  of  rules.  Option  2  allows 
the  user  to  look  at  communication  system (s)  to  see  the  set-up 
or  generate  complete  information  of  that  system.  Option  3 
completely  checks  a  system  for  any  faulting  numbering  and  will 
help  isolate  the  faults.  Option  4  will  quickly  number  a  pre¬ 
defined  system.  Select  the  desired  option  by  clicking  on  the 
appropriate  button  with  the  mouse  and  then  clicking  the  "done” 
button.  If  "user  determined  number  of  communication  systems" 
is  selected,  the  next  screen 


will  ask  for  the  number  of 
systems  to  be  generated,  see 
Figure  8 .  Enter  the  number 


by  clicking  on  the  line, 
typing  in  the  number  from  the 
keyboard,  and  then  clicking  on  the  "click  here  when  the  number 
is  entered"  button  with  the  mouse. 


Number  of  Comm  Systems  ,  1 
Click  here  when  number  is  entered  1 


Figure  8  Number  of 

Communication  Systems  Box. 
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The  next  screen  offers  the  options  on  the  hard  copy  output 


of  the  communication  system(s),  see  Figure  9: 


1.  Generate  full  comm 
system  information 
output.  This  option 
will  generate  the 
following  information 
for  each  formation: 

-country 

-unit  type (Corps, 

Division, Brigade) 

-unit  number 
-unit's  assigned  NIAC 
-single  or  multiple-router 
-duplicate-capable  or  not 
-  formation ' s  parent . 

For  each  switch  of  each  formation  the  following 
information  is  provided: 

-the  formation  connected  to  the  other  end  of  the 
trunk 

-the  numbers  in  the  incoming  and  outgoing  routing 
tables  determined  via  the  rules  the  user  selects. 
Also,  for  each  network: 

-summary  listing  of  the  area  codes  assigned  to  that 
network  is  given. 

2.  Generate  numbering  only.  This  option  gives  an 
abbreviated  version  of  the  previous  listed  option. 

The  following  information  is  given  for  each  formation: 

-country 
-unit  type 
-unit  number 
-NIAC  assigned 

The  following  information  is  given  for  each  switch: 
-the  formation  connected  to  the  other  end  of  the 
trunk 

-the  numbers  in  the  outgoing  routing  table. 

3.  Do  not  generate  Comm  System  information  Output.  This 
option  results  in  no  output  file  containing 
information  on  the  physical  configuration  of  the 
communication  system. 

The  full  output  option  gives  all  possible  pertinent 
information  about  the  communication  system  for  trouble 
shooting  purposes.  The  numbering  only  option  outputs  only 


(>n»r»te  0M.V Numbering  and  Routing  Table  Informatior  Output  ( 

DO  NOT  Generate  Comm  System  Information  Output  | 

Click  here  when  choice  is  made  ; 

Figure  9  Type  of  Output  Choice 
Box . 
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the  information  necessary  to 
number  each  formation  and 
set  up  all  routing  tables. 

If  either  of  the  two 
types  of  output  is 
rv.quested,  the  next  screen  will  ask  for  the  name  of  the  file 
to  which  the  output  will  be  written,  see  Figure  10.  The 
procedure  for  entering  the  file  name  is  the  same  as  for 
previous  files.  The  format  of  the  output  files  is  discussed 
in  Chapter  IV,  OUTPUT  FILES. 

The  next  screen  asks  if  statistical  output  is  desired  or 
not.  The  choice  is  made  in  the  manner  discussed  earlier  for 
general  output.  When  statistical  output  is  chosen  the 
following  information  is  provided  for  each  communication 
system:  the  number  of  the  communication  system,  number  of 
calls  made,  number  of  successful  calls,  number  of  failed 
calls,  and  the  percentage  of  successful  calls.  If  more  than 
one  communication  system  is  simulated,  the  same  information 
is  given  for  all  communication  systems  totaled.  A  95  percent 
confidence  interval  for  the  estimate  of  the  mean  success 
rate  is  also  given.  If  statistical  output  is  chosen,  the 
next  screen  will  request  the  name  to  which  this  output  will 
be  written.  The  file  name  is  entered  in  the  same  way  as  for 
previous  files. 

The  next  screen  asks  whether  or  not  to  use  the  rule 
modification  to  STANAG  4214  which  corrects  an  error 


Figure  10  Output  File  Name 
Box. 


91 


discovered  in  the  protocol, 
see  Figure  11 .  The  choice 
is  made  in  the  same  way  as 
for  previous  selections. 


The  following  screen 
gives  the  choice  of  whether 
to  utilize  the  anti-looping 


rules  developed  for  TACFONE- 
NATO,  see  Figure  12.  The 
anti-looping  choice  will 
institute  an  anti -looping 
heuristic  which  allows  for 
maximum  redundancy  between 
the  Host  formations  while 
preventing  looping.  This  is  implemented  through  the  routing 
table  configurations. 

The  next  option  presented  is  how  the  communication 


Ms«  Anth^looping  Rules 
DO  NOT  Use  Anti-Looping  Rules 


Click  here  when  choice  is  made  ] 


Figure  12  Anti -Looping  Rule 
Choice  Box. 


system (s)  is  (are)  to  be 
generated:  randomly  by 
TACFONE-NATO,  or  by  reading 
in  a  user  defined 
communication  system  from  a 
file,  see  Figure  13.  The 
format  for  the  user  defined 
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communication  system  file  is  discussed  in  Chapter  III,  INPUT 
FILES. 

If  the  communication  system  is  to  be  read  in  from  a 
file,  a  choice  of  how  formations  are  to  be  numbered  is 
provided.  The  choices  are:  manually  from  the  communication 
system  file  defined  by  the 
user,  or  automatically  by 
TACFONE-NATO  Utilizing  the 
STANAG  4214  protocol  and  the 
other  options  selected 
earlier,  see  Figure  14.  The 
choice  is  made  in  the  way  as  for  previous  selections.  The 
reading  in  of  user  defined  numbers  allows  for  the  testing  of 
a  numbering  scheme  that  may  not  follow  the  exact  protocol  of 
the  STANAG.  If  the  "read  comm  system  from  file"  option  is 
selected,  the  program  will  request  the  file  containing  the 
communication  system  information. 

The  next  choice  for  a  communication  system  being  read  in 
from  a  file  is  whether  to 
read  connections  for  the 
system  in  from  a  file  or  for 
TACFONE-NATO  to  generate  the 
connections  randomly,  see 

Figure  15  Connection  Choice 
Figure  15.  The  option  for  Box. 

reading  the  connections  in  from  a  file  allows  the  user  to 
define  exact  inter-host  connections  and  also  lateral 


Figure  14  Formation  Numbering 
Choice  Box. 
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connections  which  TACFONE-NATO  does  not  generate  randomly 
(all  parent -child  connections  are  always  constructed  by 
default) . 

The  model  automatically  institutes  a  method  of  updating 
the  switches'  routing  tables  that  will  not  allow  looping  to 
occur  with  lateral  connections.  The  option  of  randomly 
generating  the  connections  will  result  in  connections 
between  the  Host  formations  only,  as  prescribed  by  the 
STANAG  4214  protocol.  If  connections  are  to  be  read  in,  the 
program  will  ask  for  the  name  of  the  file  containing  the 
connections  data,  see  Figure 
16 ,  The  format  for  this 
file  is  discussed  in  Chapter 
III,  INPUT  FILES. 

At  this  point,  based  on 
the  initial  options  chosen, 

TACFONE-NATO  commences  the  run.  All  runs  present  a  window 
containing  two  level  meters  that  track  the  real  time 
percentage  of  calls  made  and  percentage  of  calls  successful 
to  that  point.  If  graphics  were  chosen,  the  communication 
system  and  the  routing  of  calls  will  be  displayed  on  the 
screen  as  previously  discussed.  For  the  user  determined 
number  of  communication  systems  option,  once  the  system  is 
generated  and  drawn,  the  option  to  generate  calls  for  the 
current  system  or  to  continue  on  to  the  next  system  is 
presented,  see  Figure  17.  This  option  is  provided  if  the 


jZONNECTDAT 

Clicic  here  when  file  name  has  been  entered  j 


Figure  16  Connection  File  Name 
Box. 
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user  wishes  to  only  observe  the  communication  system  set  up 
and  then  move  on  to  the  next  system.  In  either  case,  any 
windows  can  be  resized  at  this  point  by  clicking  and 
dragging  the  corner.  Once  the  inspection  of  the  system  is 
complete,  a  click  on  the  appropriate  choice  for  generating 
or  not  generating  calls  is  made. 

If  calls  are  to  be 
generated  for  the  system,  a 
"start  making  calls"  button 
will  be  presented,  see 
Figure  18.  This  allows  for 
an  additional  opportunity  to 
resize  any  windows  prior  to 
calls  being  generated. 

Once  calls  are  started, 
the  windows  will  not  resize 
until  either  a  call  fails  or 
the  calls  are  completed.  If  a  failed  call  occurs,  any 
window  can  be  resized  to  allow  for  closer  inspection  of  the 
situation  which  caused  the  failure.  Once  the  inspection  is 
complete,  a  simple  mouse  click  in  the  "continue"  box,  will 
resume  the  run. 

Upon  completion  of  all  calls,  a  button  is  displayed  to 
"remove  this  communication  system",  see  Figure  19.  This 
allows  the  user  to  inspect  the  system  graphically  prior  to 
either  moving  to  the  next  system  or  completing  the  model 


Cemrate  Calls  for  ihis  Comm  System 

DO  NOT  Generate  Calls  CO  to  Next  Comm  System 


Click  here  when  choice  is  made 


Figure  17  Generate  Calls  Fcr 
This  Comm  System  Box. 


Figure  18  Start  Making  Calls 
For  System  Button. 
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run.  If  more  then  one 
communication  system  is  to 
be  generated,  the  user  will 
be  presented  with  the  option 
of  making  calls  for  each  system  as  tney  are  generated  and 
drawn  on  the  screen.  Upon  completion  of  calls  for  the  last 
communication  system,  the  requested  output  is  written  to  the 
appropriate  files.  The  user  can  then  print  out  these  files 
when  desired.  The  format  for  the  output  files  is  discussed 
in  Chapter  IV,  OUTPUT  FILES. 
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Ill .  INPUT  PILES 


Figure  20  summarizes  all  possible  input  files  used  by 
TACFONE-NATO.  Formats  for  these  files  will  be  discussed 
separately. 

REQUIRED  FILES  (named  as  below) : 

AREACODE.DAT- -lists  subsidiary  area  codes  for  each 
nation. 

UNIT.DAT  --lists  units  available  from  each  nation. 

OPTIONAL  FILES  (named  as  desired) : 

Routing  Capabilities- -lists  whether  each  nation's 

communications  equipment  is 
single  or  multiple-routing 
capable . 

Duplicate  Capability- -lists  whether  each  nation's 

communications  equipment  is 
duplicate-capable  or  not. 

CommSystem  Data  --lists  the  units  of  a  manually 

generated  CommSystem. 

Connection  Data  --lists  the  connection.^  of  a 

manually  generated  CommSystem. 

Figure  20  Input  file  types. 

A.  FILES  REQUIRED  FOR  ALL  RUNS 

There  are  two  files  required  for  the  TACFONE-NATO 
simulation  model  to  work  regardless  of  the  type  of  run 
desired.  These  files  are  "AREACODE.DAT"  and  "UNIT.DAT".  The 
names  of  these  files  are  not  negotiable  and  must  be  exactly  as 
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appears  above.  The  AREACODE.DAT  file  contains  all  subsidiary 
area  codes  assigned  to  each  nation  as  per  STANAG  4214.  The 
UNIT.DAT  file  contains  information  regarding  the  number  of 
each  type  of  unit  available  from  each  nation  in  assembling  a 
NATO  force.  The  exact  format  of  each  file  will  now  be 
discussed  separately. 

1.  Format  For  AREACODE.DAT  File 

The  basic  format  for  this  file  is: 

1.  A  header  line  at  the  top  of  the  file  (exact  wording 
not  critical) . 

2.  A  single  line  for  each  nation  which  delineates  the 
area  codes  for  that  nation.  The  format  for  each  line 
is  : 

Name  of  nation,  XXX  XXX  XXX  0; 

where  the  XXX' s  represent  subsidiary  area  codes  and  the 
0  is  the  last  entry  on  the  line.  The  nations  must  be 
listed  in  the  same  order  as  they  appear  in  STT^AG  4214, 
see  Figure  21. 

As  noted,  the  order  of  nations  must  be  as  in  Figure 
21.  The  spelling,  including  capitalization,  for  each  nation 
must  be  exactly  as  in  Figure  21.  The  exact  order  of  the 
numbers  for  each  nation  is  not  critical,  but  it  should  be 
noted  that  those  numbers  appearing  first  in  the  lists  will  be 

the  first  ones  used.  The  0  at  the  end  of  each  line  is 

critical  as  it  denotes  the  end  of  subsidiary  area  codes  for  a 
particular  nation.  It  is  not  permissible  to  exclude  a  country 
from  the  list  if  it  has  no  subsidiary  area  codes.  Instead, 
simply  put  a  0  as  the  only  entry  in  its  list  of  subsidiary 

area  codes  (see  NatoComm  in  Figure  21)  .  The  list  in  Figure  21 
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Subsidiary  Area  Codes 

Eor  Each 

Nation 

Belgium 

200 

300 

400 

0 

Canada 

201 

301 

401 

0 

Denmark 

202 

302 

402 

0 

France 

818 

203 

218 

718 

303 

318 

618 

403 

418 

0 

Germany 

819 

204 

219 

719 

304 

313 

619 

404 

419 

0 

Greece 

205 

305 

405 

0 

Iceland 

206 

306 

406 

0 

Italy 

207 

307 

407 

0 

Luxembourg 

208 

308 

408 

0 

Netherlands 

209 

309 

409 

0 

Norway 

210 

310 

410 

0 

Portugal 

211 

311 

411 

0 

Turkey 

212 

312 

412 

0 

UnitedKingdom 

213 

313 

413 

0 

UnitedStates 

816 

214 

216 

716 

314 

316 

616 

414 

416 

0 

NatoComm 

0 

ComLandJut 

315 

0 

Spain 

217 

317 

417 

0 

Figure  21  Example  of  AREACODE.DAT  file  format. 


denotes  the  assignments  made  in  STANAG  4214 .  These  numbers 
may  be  changed  without  adversely  affecting  the  model. 

2.  Format  For  UMIT.DAT  File 

The  UNIT.DAT  file  determines  the  pool  of  units 
available  for  the  model  to  draw  from  when  randomly  generating 
force  structures.  The  basic  format  for  this  file  is: 

1.  A  header  line  at  the  top  of  the  file  (exact  wording 
not  critical) . 

2.  A  single  line  for  each  nation  which  delineates  the 
number  of  each  type  of  unit  available  for  force 
construction  from  that  nation.  The  format  for  each  line 
is : 

Name  of  nation,  XI  X2  X3; 

where  the  XI  represents  the  number  of  corps  available, 
X2  represents  the  number  of  divisions  available,  and  X3 
represents  the  number  of  brigades  available.  X3  is  the 
last  entry  for  a  line.  The  nations  must  be  listed  in 
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the  same  order  as  they  appear  in  STANAG  4214.  See 
Figure  22 . 


The  Number  of 

Corps, 

Divs 

,  and  Brigades  for  each  country 

Belgium 

2 

6 

18 

Canada 

1 

3 

9 

Denmark 

1 

3 

9 

France 

4 

12 

36 

Germany 

4 

12 

36 

Greece 

1 

3 

9 

Iceland 

1 

3 

9 

Italy 

1 

3 

9 

Luxembourg 

1 

3 

9 

Netherlands 

1 

3 

9 

Norway 

1 

3 

9 

Portugal 

1 

3 

9 

Turkey 

1 

3 

9 

UnitedKingdom 

2 

6 

18 

UnitedStates 

4 

12 

36 

NatoComm 

1 

0 

0 

ComLandJut 

1 

0 

0 

Spain 

1 

3 

9 

Figure  22  Example  of 

UNIT 

•DAT  file  format. 

The  order  of  nations  must  be  as  in  Figure  22.  The 
spelling,  including  capitalization,  for  each  nation  must  be 
exactly  as  in  Figure  22.  It  is  not  permissible  to  exclude  a 
country  from  the  list  if  you  do  not  wish  it  to  have  any  units 
available.  Instead,  simply  put  in  O's  for  the  number  of 
Corps,  Divisions,  and  Brigades  available  for  that  nation. 
Changing  the  numbers  in  this  file  will  only  change  the 
relative  likelihood  of  randomly  choosing  units  from  any 
particular  nation  when  randomly  generating  a  CommSystem. 

WARNING:  When  randomly  generating  a  communication 
system,  the  model  replaces  any  unit  which  requires  a  Host  to 
be  assigned  a  new  subsidiary  area  code  when  the  Host  nation 
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has  no  more  subsidiary  area  codes  to  be  assigned.  This  means 
that  It  is  possible  for  the  program  to  go  into  an  infinite 
loop  in  search  of  a  unit  which  does  not  create  this 
requirement  if  no  such  unit  exists.  Therefore,  it  is 
advisable  to  maintain  a  relatively  wide  variety  of  units 
available  from  the  different  nations. 

B.  FILES  REQUIRED  FOR  MANUAL  INPUT 

Additional  files  may  be  required  if  it  is  desired  to 
manually  enter  data  defining  some  or  all  of  the  aspects  of  the 
communication  system  to  be  analyzed.  These  files  are  not 
required  if  these  data  are  to  be  randomly  generated.  The 
formats  for  these  additional  files  will  now  be  discussed. 

1.  List  o£  Routing  Capability  for  each  Nation 

If  desired,  the  routing  capability  (single-routing  or 
multiple-routing)  for  each  nation's  communications  equipment 
can  be  read  in  from  a  file.  This  file  may  be  named  as  desired 
since  the  program  will  ask  for  the  name  of  the  file  to  be 
read.  The  default  filename  is  "ROUTING.DAT".  The  basic 
format  for  this  file  is: 

1.  A  header  line  at  the  top  of  the  file  (exact  wording 
not  critical) . 

2.  A  single  line  for  each  nation  which  delineates  whether 
that  nation's  communications  equipment  is  single -routing 
capable.  The  format  for  each  line  is: 

Name  of  nation,  BOOLEAN; 

where  BOOLEAN  represents  either  a  "True"  (single¬ 
routing)  or  "False"  (multiple-routing)  entry.  The 
nations  must  be  listed  in  the  same  order  as  they  appear 
in  STANAG  4214.  See  Figure  23. 
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Country  Single  Routing  (T=Single  Routing,  F=Multiple)  I 

Belgium 

True 

Canada 

False 

Denmark 

True 

France 

False 

Germany 

True 

Greece 

True 

Iceland 

True 

Italy 

False 

Luxembourg 

False 

Netherlands 

True 

Norway 

True 

Portugal 

True 

Turkey 

False 

Un i t e dK i ngdom 

False 

UnitedStates 

False 

NatoComm 

False 

ComLandJut 

True 

Spain 

True 

Figure  23  Example  of  Routing  data  file  format. 


Again,  the  order  of  nations  must  be  as  in  Figure  21. 
The  spelling,  including  capitalization,  for  each  nation  must 
be  exactly  as  in  Figure  23.  The  spelling  of  "True"  and 
"False"  must  also  be  as  in  Figure  23.  It  is  not  permissible 
to  exclude  a  country  from  the  list,  an  assignment  of  "True"  or 
"False"  must  be  made  for  each  nation. 

2.  List  of  Duplicate-Capability  for  each  Nation 

If  desired,  the  duplicate -capability  (duplicate- 
capable  or  not  duplicate-capable)  for  each  nation's 
communications  equipment  may  also  be  read  in  from  a  file. 
This  file  may  be  named  as  desired  since  the  program  will  ask 
for  the  name  of  file  to  be  read.  The  default  filename  is 
"NDC.DAT".  The  basic  format  for  this  file  is  the  same  as  for 
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routing  capability  except  that  a  "True"  entry  represents  not 
duplicate-capable  and  a  "False"  entry  represents  duplicate- 
capable,  see  Figure  24.  All  comments  made  about  the  Routing 
data  file  also  apply  to  the  not  duplicate -capable  data  file  as 
well . 


1  Country  Not  Duplicate  Capable  (T=NotDupCap,  F=DupCap) 

Belgium 

False 

Canada 

False 

Denmark 

True 

France 

True 

Germany 

False 

Greece 

False 

Iceland 

False 

Italy 

False 

Luxembourg 

False 

Netherlands 

True 

Norway 

False 

Portugal 

False 

Turkey 

False 

UnitedKingdom 

False 

UnitedStates 

True 

NatoComm 

False 

ComLandJut 

True 

Spain 

False 

Figure  24  Example  of  Not  Duplicate  Capable  file  format. 


3 .  Manually  Generated  CommSystem 

If  desired,  a  manually  generated  CommSystem  may  be 
entered  for  full  analysis  or  for  just  numbering  and  setting  up 
routing  tables.  A  file  containing  a  manually  generated 
CommSystem  may  be  given  any  name  desired  since  the  name  of  the 
file  to  be  read  will  be  asked  for  by  the  program. 

The  default  filename  is  "NETWORK.DAT".  The  format  for  a 
manually  generated  CommSystem  is: 

1.  A  header  line  at  the  top  of  the  file  (exact  wording 
not  critical) . 
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2.  A  single  line  for  each  unit  in  the  CommSystem.  The 
format  for  each  line  is: 

Level,  Country,  UnitType,  UnitNumber,  XXX; 

where  XXX  is  the  area  code  for  that  unit  if  it  is 
desired  to  not  have  the  model  automatically  number  the 
system.  The  units  are  entered  in  depth-first  order: 
Hostl,  Primaryl  for  Hostl,  Secondaryl  for  Primaryl  of 
Hostl,  ...,  SecondaryN  for  Primaryl  of  Hostl,  Primary2 
for  Hostl,  all  Secondaries  of  Primary2  for  Hostl,  ..., 
PrimaryK  for  Hostl,  all  Secondaries  of  PrimaryK  for 
Hostl ;  Host2 ,  .... 

3.  A  line  containing  the  string: 

"EndOfData" . 

Figure  25  illustrates  the  proper  basic  format  and 
Figures  26  and  27  show  the  CommSystem  it  represents. 


Level 

Country 

UnitType 

UnitNumber 

AreaCode 

Host 

UnitedStates 

Corps 

2 

714 

Primary 

UnitedStates 

Division 

1 

714 

Secondary 

Germany 

Brigade 

10 

816 

Secondary 

Germany 

Brigade 

11 

214 

Primary 

France 

Division 

4 

714 

Secondary 

Belgium 

Brigade 

6 

714 

Primary 

Germany 

Division 

4 

714 

Host 

Germany 

Corps 

3 

604 

Primary 

Italy 

Division 

1 

604 

Primary 

Portugal 

Division 

3 

604 

Secondary  Luxembourg 

EndOfData 

Brigade 

1 

604 

Figure  25  Example  of  format  for  reading  in  a  CommSystem. 


There  is  no  limit  to  the  number  of  Primaries  may  be 
assigned  to  a  Host  or  Secondaries  to  a  Primary.  The  spelling 
of  all  words  is  critical  however.  "Host",  "Primary"  and 
"Secondary"  must  be  spelled  and  capitalized  as  shown;  the 
countries  must  be  spelled  and  capitalized  as  shown  in  the 
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Figure  26  Network  2. 


Figure  27  Network  1 . 


AREACODE.DAT  file  example  (Figure  21),  and  the  spellings  for 
"Corps",  "Division",  and  "Brigade"  follow  suit.  There  are  no 
allowed  unit  types  other  than  "Corps",  "Division",  and 
"Brigade".  The  only  restriction  on  unit  numbers  is  that  they 
must  be  an  unique  integer  entry.  An  area  code  must  be 
assigned  even  if  the  program  is  going  to  automatically  number. 
It  is  recommended  to  simply  enter  0  for  the  area  code  in  this 
case.  All  data  in  the  file  after  the  "EndOfData"  line  will  be 
ignored . 
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4.  Manually  Connecting  a  CommSystem 

If  desired,  when  a  CommSystem  is  manually  generated, 
the  exact  connections  between  Hosts  may  be  manually  entered 
through  a  file,  rather  that  have  the  program  randomly  generate 
them.  This  input  file  also  allows  for  the  insertion  of 
lateral  connections.  NOTE:  All  formations  will  automatically 
be  connected  to  their  parent /children  so  it  is  not  necessary 
to  put  these  connections  in  the  file.  Only  enter  inter-host 
and  lateral  connections.  A  file  containing  the  connections 
for  a  manually  generated  CommSystem  may  be  given  any  name 
desired  since  it  will  be  asked  for  by  the  program.  The 
default  filename  is  "CONNECT.DAT".  The  format  for  a  manually 
connections  is: 

1.  A  header  line  at  the  top  of  the  file  (exact  wording 
not  critical) . 

2.  A  single  line  for  each  connection  desired.  The  format 
for  each  line  is: 

Countryl,  UnitKindl,  UnitNumberl,  Country2,  UnitKind2, 

UnitNumber2 ; 

where  the  first  three  entries  identify  one  of  the  units 
to  connect  and  the  second  three  identify  the  second  unit 
to  connect.  Figure  28  illustrates  the  proper  basic 
format . 

3.  A  line  containing  the  string  "EndOfData" . 


Again,  spelling  of  all  words  is  critical  and  must  be 
as  previously  mentioned.  There  is  no  limit  to  the  number  of 
connections  which  can  be  made.  The  program  will  not  connect 
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Count ryl 

UnitKindl 

Numl 

Country 2 

UnitKind2 

Num2 

UnitedStates 

Corps 

2 

Germany 

Corps 

3 

Italy 

Division 

1 

Portugal 

Division 

3 

Germany 

EndOfData 

Brigade 

10 

Germany 

Brigade 

11 

Figure  28  Example  of  format  for  reading  in  connections. 


two  units  more  than  once  although  an  attempt  to  do  so  will  not 
harm  the  program.  If  an  attempt  is  made  to  connect  a  unit  to 
itself  or  to  a  unit  which  does  not  exist  (existing  units  can 
be  obtained  from  the  file  containing  the  read  in  CommSystem) , 
the  program  will  notify  the  user  of  the  problem  and  terminate 
execution.  It  is  the  user's  responsibility  to  ensure  that  the 
Hosts  are  connected  so  as  to  comprise  at  least  a  minimum 
spanning  tree.  Failure  to  do  this  will  result  in  numerous 
failed  (dead-end)  calls. 
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IV.  OUTPUT  PILES 


There  are  two  types  of  output  files  that  can  be  chosen  in 
the  initial  options  menus.  Both  options  will  have  a  header 
that  appears  as  follows: 

"This  output  was  generated  on:  Mon  Aug  4  09:15:15  1993". 
The  date  and  time  will  allow  the  user  to  identify  different 
runs  that  may  have  similar  force  structures.  The  first  option 
of  generating  full  communication  system  output  lists  the 
information  discussed  previously  in  the  format  shown  in  Figure 
29. 


Information  For  Network  1 
Formation  Number  1 
Formation  Level:  Host 

Country:  UnitedStates  Unit  Kind:  Corps  Unit  Number:  2 
Not  Duplicate  Capable  Multiple  Routing 
National  Identifier:  914  Area  Code:  604  NIAC:  904604 
External  Switch  1  is  connected  to: 

Country:  Germany  Unit  Kind:  Corps  Unit  Number:  3 
National  Identifier:  904  Area  Code:  604  NIAC:  904604 
The  outgoing  routing  table  contains  the  following  numbers: 
604  819  204 

The  incoming  routing  table  contains  the  following  numbers: 
714  816  214 

Internal  Switch  1  is  connected  to: 

Country:  France  Unit  Kind:  Division  Unit  Number:  4 
National  Identifier:  903  Area  Code:  714  NIAC:  903714 
The  outgoing  routing  table  contains  the  following  numbers: 
903714  900714  917816 

The  incoming  routing  table  contains  the  following  numbers: 
914714  904816  904214  904714  604  819  204 


Figure  29  Full  Communication  System  information  output 
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The  same  information  is  given  for  each  formation  in  the 
communication  system.  The  external  switches  are  switches 
connecting  the  formation  to  formation  in  another  network.  The 
internal  switches  connect  the  formation  to  a  formation  within 
it's  network. 

The  option  for  numbering  information  only  gives  an 
abbreviated  version  of  Figure  29,  the  information  on 
communication  equipment  capabilities  and  incoming  routing 
tables  is  not  given.  The  switch  information  is  no  longer 
displayed  as  external  and  internal,  just  a  listing  of  the 
switches,  what  formation  it  is  connected  to  and  the  outgoing 
routing  table  contents.  An  example  of  this  output  cau  be  seen 
in  Figure  30. 

The  Statistical  output  lists  the  options  chosen  for  the 
use  of  anti-looping  rules  (or  not),  the  use  of  the  STANAG 
numbering  rule  change  and  the  type  of  run  at  the  top  of  the 


Information  For  Network  1 
Formation  Number  1 
Formation  Level:  Host 

Country:  UnitedStates  Unit  Kind:  Corps  Unit  Number:  2 
National  Identifier:  914  Area  Code:  604  NIAC:  904604 
Switch  1  is  connected  to: 

Country:  Germany  Unit  Kind:  Co'^ps  Unit  Number:  3 

The  outgoing  routing  table  contains  the  following  numbers: 

604  819  204 

Switch  2  is  connected  to: 

Country:  France  Unit  Kind:  Division  Unit  Number:  4 
The  outgoing  routing  table  contains  the  following  numbers: 

903714  900714  917816 _ 

Figure  30  Numbering  only  information  output. 
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output  file.  The  information  provided  from  each  run  is  the 
communication  system  number,  the  run  number,  the  number  of 
calls  made,  number  of  successful  calls,  number  of  failures, 
and  the  success  rate.  The  same  information  is  provided  for 
the  totals  of  each  communication  system  and  the  total  all 
communication  systems.  The  estimated  mean  percent  successful 
calls,  estimated  variance  and  the  95  percent  confidence 
interval  are  also  provided  at  the  top  of  the  output  when  the 
type  of  run  is  "calculate  percent  successful  calls".  Figure 
31  is  an  example  of  this  output  file. 


110 


Anti -Looping  rules  not  used. 

Numbering  change  implemented. 

Only  one  path  checked  for  each  call. 

Estimated  percent  successful  for  a  CommSystem  =  90.52407 
Estimated  Variance  of  average  percent  successful  =  153.82617 

Ninety-five  percent  Confidence  Interval  = 
(86.087169,94.963644) 


pList  of  results  for  each  run: 


CommSystem 

Run 

Calls 

Successes 

Failures 

Success 

Rate 

1 

1 

5852 

4075 

1777 

69 . 63 

1 

2 

5852 

4185 

1667 

71.51 

30 

29 

4970 

3950 

1020 

79.48 

30 

30 

4970 

3992 

978 

80.32 

List  of  results  for  each 

CommSystem: 

CommSystem 

Runs 

Calls 

Successes 

Failures  Success  Rate 

1 

30 

175560 

123025 

52535 

70.08 

30 

30 

149100 

118465 

30365 

79.45 

rTotal  results: 


CommSystems  Calls  Successes  Failures  Success  Rate 
1  2850300  2287056  563244  80.24 


Figure  31  Statistical  output. 
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